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 
assure you.

>Specific comments:
>
>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 
with this?

>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
>replacement package.
>
>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.

Adam