Subject: RE: Apropos package upgrading.
To: Hubert Feyrer <hubert.feyrer@informatik.fh-regensburg.de>
From: Dave Burgess <burgess@neonramp.com>
List: tech-pkg
Date: 03/19/2001 17:07:23
As many of you already know - I run a network of about 25 NetBSD servers at
a local Internet Service Provider.

I have been upgrading the servers from 1.4.3 to 1.5 (with the attendant
upgrades from a.out to ELF) by hand for the past month and a half; I am
almost through.  The toughest part of the problem is that I don't want to
waste time recompiling the same program over and over from a 'make update'.
If a compiled package is up to date, I wish there was some way the make
program could recognize that and not recompile it.  If the package has been
updated, I want the program to recognize that and recompile it, otherwise if
I want the package deleted, I'll 'make clean' it.  Giving 'make' access to
the packages database would work for me; if it could figure out what the
package name is and compare it to the current package that's installed, it
would meet my needs.  Even if we don't have an automated method, if we could
just get the packages to display in the order they were registered, I would
be a happy person.

My theory is that, generally, the dependencies are time sensitive.  Of
course, there are exceptions, but for the most part it works.  For example,
when I installed PERL on my 1.4.3 server 15 months ago, I also installed a
couple of other things at the same time.  The additional stuff required
PERL, but that was OK, since I used the package system to install it
originally.  When I go through the list, it's usually in the order in which
everything was originally installed, so as I go through, I end up doing the
following:

pkg_info -aBR | lpr
cd /usr/pkgsrc/*/whatever (from the list above, making sure I get all of the
dependencies)
pkg_delete -f whatever
make reinstall

If anything is missing, I install that.  If there are any required programs
that are missed, they either get automatically installed, or get installed
at the end.  If they aren't reinstalled automatically, I can go back and do
them by hand, then re-reinstall the package one more time.  If life were
perfect, the pkg_info list would show them in the order in which they were
registered (vice actually installed) so that I know the dependencies are OK.

My database server was the toughest, because there are dozens of modules for
mysql (mysqladmin, p5-whatever, php-stuff, etc.).  It took me about three
hours to get all of the packages reinstalled.

One of the other things that I have started doing is building all of my
packages on my fastest server and using NFS to mount it from the rest of the
systems for the entire pkgsrc directory.  This way, I don't end up
rebuilding every package after a 'make update', even though this would be
the easiest (theoretically) way to install the new packages.

Of course, there are always problems (at least one per server).  An example
is in my NOC Monitoring system, where I needed the Net::UDP CPAN
distribution.  What I should have done was put it into a pkgsrc package, but
instead I just installed it through CPAN.  That decision will haunt me, I'm
sure.  Amanda was problematic, since 'addnerd' is no longer required.
Anything that needs OpenSSL is another area of possible confusion.

Given that the current package system is intended for (basically) as single
computer installation, what I would much rather see are the following:

1)  A tag in the Makefile that actually gave the real package name.  Having
macros in the package names is real cute, but I don't see the possible
purpose.  It's not like it's retyped over and over again.  It appears once:
at the top.  By the way, to whoever put the distribution directory into the
pkg_info table - THANK YOU VERY MUCH.

2)  Some kind of way to enforce package registration dates.  Right now, I
don't know what the ordering mechanism is, and I'm trusting basically to
what appears to be blind luck that it works at all.  Once in a while (on a
couple of servers) the normal ordering has failed me, but it's been OK so
far: nothing I couldn't solve with a little mental exercise.

If I had these two things, a script that reinstalls the entire installed
base (and just the installed base) based on whether or not a package had
been updated would be a real possibility.  I've got most of a script like
that built now, but it's still problematic.  I've got the dependency graph
about 80% done.  One of the egregious hacks I'm doing is checking the date
on the 'work' directory against the 'Makefile'.  This works OK, but only
once.  After that, the '.install' file changes the date and none of the rest
of the updates work.

Something where I go to '/usr/pkgsrc' and simply type 'make update' would be
wonderful, but I've been studying the problem, and it *IS* a tough nut to
crack.  It's probably too hard a problem for a shell script.

Dave