Subject: Re: Ruminations on pkg_chk...
To: Greg Troxel <email@example.com>
From: Adam C. Migus <firstname.lastname@example.org>
Date: 12/31/2003 18:25:50
Greg Troxel wrote:
> 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.
I strongly disagree. I've used portupgrade extensively for quite some
time on a number of my servers and find it quite painless. As long as
you run it regularly it keeps everything up-to-date and seldom has
problems dealing with errors. It takes care of the duplicate builds
problem, properly sorts dependencies, has a 'do nothing' mode for
dry-runs, etc. If you have two systems I've found the ideal
configuration is to run one server as a 'test-production' server which
builds from source and saves a binary package then if the package works
the other runs portupgrade in 'upgrade from binary package' mode using
the packages built by the other. Works quite well. Quite painless I
>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
> multiple packages.
How? I've used FreeBSD ports for years and have never seen this...
Care to elaborate? The multiple versions of libraries are usually
tucked away in lib/compat after an upgrade to insure packages continue
to work after upgrades, as you point out below.
>2. IIRC portupgrade is written in ruby, so you have to have that
> installed. This has not been a hassle in practice.
Once you install portupgrade it will manage itself and it's dependencies
(including ruby) as part of normal business. So what's the big deal
>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.
Portupgrade does this automatically if it sees they're out of date.
>4. When all the dbs are in sync and the ports installation is 100%
> straightened out, portupgrade works very smoothly.
And if you use it correctly this will be the case 100% of the time.
>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
> cool feature.
>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.
So administrate your system properly. Unless of course you can explain
how exactly you get to a point where you have multiple versions of a
port installed without intentionally misusing the ports-system it's your
fault, not the ports-system.
>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.
Cool idea's but I'm not sure you gave portupgrade a fair shake.