Re: Keeping FreeBSD 5.2 up-to-date

From: Andrew Reilly (andrew_at_gurney.reilly.home)
Date: 02/03/04 

Date: Tue, 03 Feb 2004 21:57:08 GMT

On Tue, 03 Feb 2004 13:14:53 -0800, MSG wrote:
> Do 3 seconds sound like an unreasonable time?

It depends on the day, and what's happened in the world of OSS. Most
weeks, yes, my upgrade takes about that much of my time. Some times,
though, it takes a bunch more, when the upgrade involves manually fetching
a new java tarball, or realizing that an upgrade of sane-backends has
overwritten /usr/local/etc/sane.d/snapscan.conf again. In 10000 ports,
most with compile-time switches, you have to expect the odd glitch. Last
week, for example, the regular upgrade did something weird to my X
installation, and I had to reset all of my desktop font preferences.

> Just to clarify: I did
> not want to spend more than 3 seconds a week of *my* time maintaining my
> workstation. I don't mind it if the OS compiles stuff all Sat night. I
> just don't want to babysit it through the process myself. 3 seconds is
> about how much of my time I spend maintaining Debian 3.0 (the machine
> itself may spend minutes to d/l and unpack things, when large binaries
> need to be updated)
>
> So, what is the magic word^H^H^H^Hcommand? i.e. translate `apt-cache
> update && apt-get upgrade` into BSD for me, if such a translation exists
> (<ADHD>!!!!!!! it should keep both the base system and ports/packages
> patched/bug-fixed !!!!</ADHD>) LOL

For the base system, I run this script as sudo nice -n 19 weekly_build:
cd /bin/sh
make buildworld && make kernel && make installworld && mergemaster

Note that that is *not* the approved sequence of operations, because
there's a slight chance that the installworld will install a binary that
won't run on the still-running old kernel. There's also the chance that
the new kernel will be broken somehow, but neither occurrence has bitten
me in many, many years (tracking _STABLE). You have to do all that in an
interactive session, because the last step, mergemaster, requires manual
intervention. That's the semi-automated process of upgrading the system
configuration files in /etc. Mostly it's harmless, but every now and then
someone will make a change to passwd or groups or inetd.conf, and then you
have to merge your local changes and the system changes back together.
After you've finished with mergemaster, I reboot, so that all of the new
stuff is running. Oh: the actual cvsup operation that updates the source
tree happens in a cron job, because it doesn't break, and doesn't lead to
any manual intervention. I suppose that I could run the make buildworld
and make buildkernel steps in the cron job too...

As a second step, I run portupgrade, which is itself a port, to keep the
ports in place. I do this in two steps, as: portupgrade -aF (the other
flags, -vwWrRbl /tmp/portupgrade.log are set in an environment variable),
to fetch all of the necessary tarballs, and then portupgrade -a to do the
building. Again, I could run the portupgrade -aF in the cron job, but
that often requires manual intervention, when a dependency in the port
database has changed. Then you need to run pkgdb -F and fix it. I have
477 ports installed, currently, and a dependency needs fixing more often
than not. Fixing dependencies is usually trivial, but sometimes it
involves some detective work, and even reconstructive surgery. The
portupgrade fetch step also requires intervention when one of the ports to
be upgraded is java, or something like it, which has a licence that
requires you to fetch it manually, so that you can click an "ACCEPT"
button.

The last step, portupgrade -a, builds and re-installs the ports that need
upgrading in the appropriate dependency order. This hardly ever falls
over, if the pkgdb -F and portupgrade -aF steps have succeeded. Some
ports (ghostscript and mgetty, from memory) are annoying because they have
manual configurators that run as part of the installation step, and if
you're not watching your computer, then it'll just stop there until you
notice and do whatever is necessary for the install. I suspect that there
is a way to run in a batch mode where it just doesn't stop. I doubt that
there's a mechanism to run portupgrade in a build-only and install-only
mode, because of the way that some ports are build-dependencies of others.

Easy. 

-- 
Andrew