Subject: Re: Ruminations on pkg_chk...
To: Bruce J.A. Nourish <email@example.com>
From: Greg Troxel <firstname.lastname@example.org>
Date: 12/31/2003 10:07:20
On the same note, what do people think of the portupgrade stuff in
FreeBSD? I've just acquired a FreeBSD box to experiment on. One problem
I can see is that it requires a binary INDEX.db that must be generated
on the host with the ports tree. This would make it hard to share a
pkgsrc tree across multiple machines by NFS, which is what I do at home.
Perhaps it's worth it, though...
It seems cool, but it can be quite painful in practice. In my
department we have a number of both NetBSD and FreeBSD machines. Our
sysadmin regularly updates each box along netbsd-1-6 or RELENG_4
branches, and also keeps pkgs/ports up to date. He has been using
portupgrade. My conclusion from observing all this as well as using
portupgrade on my own box (I won't speak for him) is that portupgrade
and FreeBSD ports is pretty scary to maintain, and that pkgsrc is far
easier to deal with. My own box has since been moved to NetBSD, and
pkgsrc is one of the reasons.
1. In FreeBSD ports, one can install multiple versions of a package.
When starting to use portupgrade, we usually find that there are
multiple versions of a lot of libraries, with many files claimed by
2. IIRC portupgrade is written in ruby, so you have to have that
installed. This has not been a hassle in practice.
3. portupgrade is an add-on, so it has new commands for lots of
package operations in order to keep its extra databases in sync.
The dbs get out of sync if you do regular operations, and then you
have to rebuild them.
4. When all the dbs are in sync and the ports installation is 100%
straightened out, portupgrade works very smoothly.
5. The basic operation of upgrading is somewhat like 'make replace',
except that (I'm fuzzy on the details) it keeps old .so versions
around to not break programs linked against them. This is a very
The lessons I take from all of this is:
1. Having a pkg system allow multiple installs of a package with
overlapping file sets is madness, and causes a lot of trouble.
It's annoying to have to make update a library when building a
package with pkgsrc sometimes, but a net win in time spent.
2. Any new databases should probably be integrated into pkgsrc proper
so that they are maintained during normal package operations.
3. Having a strategy to keep older versions of libraries around is
very useful, and means that packages don't break when you upgrade
their dependent libs so often.
So, it would be cool if make replace could diff the PLISTs, and if
there is an 'old' .so version, create a new splinter package
registration of just those files, and change the dependencies of all
depending packages to include both the new splinter package and the
Further, the splinter package could be marked as 'second class',
meaning that it only exists to support other packages, not because
anything wants it, and automatically deinstall it when the last
depending package is removed.
Greg Troxel <email@example.com>