Port request: rpm_select (and other rpm port improvements)

[cooljeanius (Eric Gallager)]

Currently there are a number of rpm ports, and the default rpm that a lot of other ports depend on is the very old rpm 4.4, which has issues. The current "rpm" port should be renamed "rpm44", all ports that currently depend on just-plain "rpm" should have their dependencies updated*, and an "rpm_select" port should be introduced to allow users to select the default rpm version.

*Currently the following ports depend on just-plain rpm:

gl00b05047:macportsscripts root# port echo depends:rpm
apt-rpm                         
poldek                          
rpm2html                        
smart                           
yum                             
yum-arch                        
createrepo                      

[afb@…]

The rpm45, apt-rpm, poldek, and yum-arch ports are abandoned/obsoleted and can be deleted...

The others are just outdated, but there is no major reason to keep all 7 versions of rpm around:

• rpm
• rpm45
• rpm50
• rpm51
• rpm52
• rpm53
• rpm54

Especially not when there is no interest in doing packaging for MacPorts, like with OpenDarwin ?

I don't think anyone is actively using the "port rpm" command, all preferring the .tbz2 archives

[larryv (Lawrence Velázquez)]

Replying to afb@…:

The rpm45, apt-rpm, poldek, and yum-arch ports are abandoned/obsoleted and can be deleted…

I’d be down with that.

The others are just outdated, but there is no major reason to keep all 7 versions of rpm around:

Probably not. Maybe we could get rid of everything except rpm54.

Especially not when there is no interest in doing packaging for MacPorts, like with OpenDarwin?

I’d say this is an accurate assessment. MacPorts does have a lot of “features” that are probably used by single-digit numbers of people.

I don't think anyone is actively using the "port rpm" command, all preferring the .tbz2 archives

There’s a port rpm command?

[cooljeanius (Eric Gallager)]

Replying to afb@…:

The rpm45, apt-rpm, poldek, and yum-arch ports are abandoned/obsoleted and can be deleted...

yum-arch at least still works though...

Especially not when there is no interest in doing packaging for MacPorts, like with OpenDarwin ?

Um, I'm personally interested in someday moving to OpenDarwin/PureDarwin...

[afb@…]

Replying to larryv@…:

Especially not when there is no interest in doing packaging for MacPorts, like with OpenDarwin?

I’d say this is an accurate assessment. MacPorts does have a lot of “features” that are probably used by single-digit numbers of people.

I'd go with "a binary number", but I guess those are single digits.

I don't think anyone is actively using the "port rpm" command, all preferring the .tbz2 archives

There’s a port rpm command?

Q.E.D. :-) (there's even a "port srpm", for making source packages)

[cooljeanius (Eric Gallager)]

Replying to larryv@…:

Especially not when there is no interest in doing packaging for MacPorts, like with OpenDarwin?

I’d say this is an accurate assessment. MacPorts does have a lot of “features” that are probably used by single-digit numbers of people.

That's what makes it my favorite package manager on OS X though! I prefer having all the power available to me even if I'm not necessarily going to use it all the time.

I don't think anyone is actively using the "port rpm" command, all preferring the .tbz2 archives

There’s a port rpm command?

There's also a port dpkg command, as there's some interest in packaging for various Linux distros, such as Ubuntu: for example, see:

• this thread on the mailing lists: ​https://lists.macosforge.org/pipermail/macports-users/2013-February/031955.html
• this ticket: #32530 and the page it links to: ​https://code.launchpad.net/~rudloff/+archive/macports

[afb@…]

Replying to egall@…:

Especially not when there is no interest in doing packaging for MacPorts, like with OpenDarwin ?

Um, I'm personally interested in someday moving to OpenDarwin/PureDarwin...

He's dead, Jim.

And to be honest it wasn't even very much fun while it lasted. (Using Darwin OS)

But it's still a worthy goal for philosophical reasons, even if not for financial ones...

[afb@…]

Replying to egall@…:

There's also a port dpkg command, as there's some interest in packaging for various Linux distros, such as Ubuntu: for example, see:

• this thread on the mailing lists: ​https://lists.macosforge.org/pipermail/macports-users/2013-February/031955.html
• this ticket: #32530 and the page it links to: ​https://code.launchpad.net/~rudloff/+archive/macports

The "port dpkg" command is probably best off deleted, can't think of a purpose for it (and the format is even worse than the xar).

Other thread is interesting, but was more about the .deb packaging of MacPorts itself (similar to the .pkg installer for Mac OS X)

Sentence should be removed from the home page, but it was still worthwhile at the time to port "base" over to FreeBSD and Linux.

At least as long as it doesn't use more of Cocoa than it does, when the Objective-C rewrite is done then that won't work anymore.

As for using the actual ports, those are probably useless. There's a fair amount of them that won't even work on Darwin... ;-)

[cooljeanius (Eric Gallager)]

Replying to afb@…:

Replying to egall@…:

Especially not when there is no interest in doing packaging for MacPorts, like with OpenDarwin ?

Um, I'm personally interested in someday moving to OpenDarwin/PureDarwin...

He's dead, Jim.

PureDarwin was updated as recently as this last December: ​http://www.puredarwin.org/news/newpuredarwin9l30betarelease

But it's still a worthy goal for philosophical reasons

Exactly, which is why I intend to get more involved in breathing life into the PureDarwin project.

[cooljeanius (Eric Gallager)]

Replying to afb@…:

Replying to egall@…:

There's also a port dpkg command, as there's some interest in packaging for various Linux distros, such as Ubuntu: for example, see:

• this thread on the mailing lists: ​https://lists.macosforge.org/pipermail/macports-users/2013-February/031955.html
• this ticket: #32530 and the page it links to: ​https://code.launchpad.net/~rudloff/+archive/macports

The "port dpkg" command is probably best off deleted, can't think of a purpose for it (and the format is even worse than the xar).

dpkg is a good enough format for Fink and Cydia at least

At least as long as it doesn't use more of Cocoa than it does, when the Objective-C rewrite is done then that won't work anymore.

iirc the Objective-C parts of MacPorts work on other platforms that use Gnustep, which is why there are configure checks for Gnustep and stuff in base.

[larryv (Lawrence Velázquez)]

Cc Me!

[larryv (Lawrence Velázquez)]

Well, this has certainly gone off topic.

PureDarwin and rpm and yum and dpkg are all well and good, but the fact of the matter is that our primary platform is OS X. Every additional port and every additional bit of functionality adds complexity and makes support more difficult, especially when maintenance tails off. “Because I personally use it” or “because someone could maybe use it” are not sufficient reasons to keep stuff around.

[afb@…]

It is not as off-topic as it might seem... There was a real use case of using the open rpm format instead of the proprietary pkg format, so that one could make packages even on a "Open" or "Pure" version of Darwin. Thus exists the "rpm" port, which was intended to provide both rpmbuild for the "port rpm" command and the rpm means to install it afterwards. And some tools like apt-rpm or smart, to help manage those. Then there is the other use case, which is looking at RPMS for Linux but still on your Mac. There tools like yum and createrepo are useful, to avoid having to use a virtual machine for those tasks.

But you are probably right about the number of ports, and those were the binary figures I mentioned: "I use it myself" (1) or "someone might use it" (0). But that's a different issue than the just the age or the most used platform of a software. And rpm isn't exactly the only port that MacPorts keeps myriads of variants of, just because it can't be decided which version to be providing. It would be nice if there was a real fix for versions of dependencies, so that port could handle things like python or db or rpm without ports. Maybe groups and subports can be leveraged as a better alternative than variants and select ?

Anyway, it seems useless to rename "rpm" to "rpm44" just because the others have numbers in them.

And it's all "rpm", so there is no way to install more than one and thus no need for a "select" either ?

[cooljeanius (Eric Gallager)]

Replying to afb@…:

Anyway, it seems useless to rename "rpm" to "rpm44" just because the others have numbers in them.

And it's all "rpm", so there is no way to install more than one and thus no need for a "select" either ?

Well, ok, I'll accept that, but I still think there should be some sort of cleaning up of the different versions of rpm ports here...

[afb@…]

See #36318.

One solution is to keep just one of each, rather than having rpm48/rpm49/rpm410/rpm411 and rpm45/rpm52/rpm53/rpm54 ?

But it's "easier" to just keep rpm 4.4.x around forever, than actually making some decisions on what software to keep in the tree.

​Consistency

[afb@…]

And #29739 plus r76683.

[afb@…]

Also, r12697 and r12699.

[larryv (Lawrence Velázquez)]

Replying to afb@…:

One solution is to keep just one of each, rather than having rpm48/rpm49/rpm410/rpm411 and rpm45/rpm52/rpm53/rpm54 ?

But it's "easier" to just keep rpm 4.4.x around forever, than actually making some decisions on what software to keep in the tree.

Are there other ports that absolutely require specific versions of rpm, in the way that some ports can’t use Python 3.x and thus need Python 2.x? I don’t really know anything about rpm.

[afb@…]

Suggest to keep just "rpm", and remove all others. Then the default port can be upgraded, if/when there is such a use case...

Delete these ports:

• rpm52
• rpm53
• rpm54
• db51
• db52
• db53

And then add a rpm-devel to track the latest CVS if wanted, and maybe keep db60 around even if it has license issues (AGPL-3) ?

No need for rpm_select.

---

PS. The port rpm and port dpkg commands have been removed from MacPorts, as per r123004, in favor of the official .tbz2.

[afb@…]

Kept "rpm" (using sqlite) and "rpm54" (using "db60", kept "db53" for others).
The rpm52 and rpm53 ports should be removed, like rpm50 and rpm51 was.