Alternate strategy for ports / portupgrade

[Garance A Drosehn]

Hi.  gad at FreeBSD here.  My life at work and "on the personal front"
continues to be a time-consuming morass, so I haven't contributed
much to FreeBSD discussions for the last few years.

I wanted to bring up a strategy I have used for ports in the threads
on "the ports collection has some serious issues", but that thread has
gone all over the map while I've been swamped at work (due to the end-
of-semester rush here at RPI).  So, here's a new thread just to make a
few observations:

1) running a ports collection of the magnitude of the FreeBSD ports
   collection is a massive challenge.  Hats off to anyone who works
   on any of the tools for it.  It's easy to see why people might
   get burned out while working on ports.

2) I happen to use portupgrade, possibly just because I like ruby.
   I did try using poudriere, but it doesn't happen to work well for
   my current systems.  I could certainly see using poudriere (or
   maybe synth?) in the future, if my situation changes.

3) I'm not here to debate what anyone else should use.  This is just
   a short note about a strategy that I've used a few times, and
   which has worked well-enough for me.

Like anyone else, I sometimes get into situations where my set of
ports is "in a mess", and I have trouble upgrading some package or
groups of packages.  I would guess that I end up in this kind of
mess every 18-24 months, on average.

Here's a terse description of how I extract myself from that mess.

On all my machines I have plenty of disk space.  So I create
duplicates of '/', '/var', and '/usr'.  Also, I have '/usr/ports'
in a partition of its own.  I unmount /usr/ports, and then mount:

  #  df -kl
  /dev/ada0p39   1586716   823228   636552   56%   /xx/rePort
  /dev/ada0p40   2082716   538732  1377368   28%   /xx/rePort/var
  /dev/ada0p41   9016380  3389188  4905884   41%   /xx/rePort/usr
  /dev/ada0p33   5450748   898376  4116316   18%   /xx/rePort/usr/ports

I execute:
  #  mount -t devfs   devfs /xx/rePort/dev
  #  mount -t fdescfs fdesc /xx/rePort/dev/fd

so that I'll also have:
  devfs                1        1        0  100%   /xx/rePort/dev
  fdescfs              1        1        0  100%   /xx/rePort/dev/fd

I then have one session chroot-ed into '/xx/rePort', and another
remaining outside of that.  In short, I then blow away all ports which
are inside 'rePort', and build my entire collection up from scratch.
This also forces me to look over all the ports I have, and sometimes
that is a good idea all by itself.  This is always a good time to try
upgrading to new major-versions of perl and python, for instance.

Now I'm skipping over a lot of details here, but the basic idea is to
build a brand-new /usr/local from scratch, *WITHOUT* touching anything
is currently in /usr/local.  I can test many of those packages by
running them inside the rePort chroot, and I can do a variety of
comparisons between the active /usr/local (config files, etc) and the
new one.

Note that I can do this at my own pace.  Maybe it'll take me a week or
two, building and cross-checking ports in my spare time.  And once I'm
optimistic enough, I'll rsync /xx/rePort/usr/local back to /usr/local-new
on the real system.  I can then try switching between the old and new
via 'mv /usr/local /usr/local-old && mv /usr/local-new /usr/local'.

There's additional work to move info under '/xx/rePort/var' to where
it belongs in the real '/var'.  There's some other things I do, but
this message is already pretty long.  I also have some notes on ways
that maybe this could be improved, assuming I ever have the spare time.
(I'll also note that I make snapshots of all the rePort partitions
before I start, so that I can use those snapshots to find *everything*
which has changed under rePorts when I'm done).

I just thought I'd mention this idea, in case it might help out
someone who finds themselves in a mess when upgrading ports, and
they can't afford a lot of downtime to clean up the mess.

Cheers to all, and to all a good night.

-- 
Garance Alistair Drosehn                =     drosih at rpi.edu
Senior Systems Programmer               or   gad at FreeBSD.org
Rensselaer Polytechnic Institute;             Troy, NY;  USA