Maybe if this shirt is witty enough... - package manager comparisons: the ports [entries|archive|friends|userinfo]
Attck of teh AzN Cow flu!

[ website | Myspace ]
[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

package manager comparisons: the ports [Nov. 11th, 2007|01:45 am]
Previous Entry Add to Memories Share Next Entry
There are about 4 widely used centralized package management systems related to, or descended from FreeBSD ports: ports, pkgsrc, portage, MacPorts.

Here are some advantages and disadvantages of each:

/usr/ports: the original.
Pros: works quite well for me. It has a good balance of flexibility, user control, and ease of use. Recently, ports started supporting "make knobs" via ncurses menus, and caching such configuration information in /var/db/ports. Also, vulnerability information is stored centrally via VuXML and the ports build infrastructure can inspect and both audit installed ports as well as refuse to install vulnerable ones.
Cons: only really works with FreeBSD/OpenBSD; so you can't really use it on any other platform. Usability for someone wanted more automation; portupgrade is hard to use (I don't trust it myself). Inability to handle concurrently installed versions of ports, except if the entire framework is modified to support such a thing (i.e. automake-versions).

pkgsrc: originally a fork of FreeBSD ports. Adopted by NetBSD and DFlyBSD (and others). One of the reasons for the adoption of pkgsrc is that port maintenance is reported to be easier for the maintainer, compared to the FreeBSD ports tree.
Pros: it's been ported to many platforms, so its ideal to use when not using Free/OpenBSD as the base OS.
Cons: I haven't used it at all so I can't really assess this. I would of course be interested in seeing if it has all the pros of the original.

portage: Attempt to port ports to a Linux platform, leading to Gentoo. A good idea in concept, but many problems:
1. The entire OS depends on the ports infrastructure; leading to the problem of not having a base+ports segregation.
2. #1 wouldn't be as much of a problem, except that it does not track removal dependencies - that is it does not enforce disallowing package A to be removed if B depends on it (except in certain undocumented special cases, i.e. the kernel). The basic fact is, REQUIRED_BY no longer exists!
3. The USE-flag situation is untenable; there was nothing wrong with supporting "make knobs" in each port's separate Makefile.

MacPorts: A ports system for OS X.
Pros: Its main cool feature is some support for version control of installed ports, and thus has an extensive database facility for storing information about active, inactive, installed, updated, and uninstalled ports.
Cons: Predefined sets of port "variants" are used in place of build-time configuration (so there is no option of specifying different combinations of "make knobs"). There does not seem to be any way to access the ports repo on the web.

pkgsrc, portage, and MacPorts also all lack a unified vulnerability tracking mechanism (i.e. VuXML).

The main reason for this comparison is to try to determine the best one to either port or mate with an appropriate Linux distribution, in my quest to obtain the perfect Linux distribution. To this end, it seems like a LFS base + pkgsrc would be the way to go. Just have to write a LFS base management system and then hand off everything else to pkgsrc. The LFS base would contain just the necessary binaries to bootstrap pkgsrc. LFS base changes would be maintained in its own svn or cvs tree.
LinkReply