Re: upgrading pkgsrc, and variations on the theme of bin-install

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Thu, 16 Oct 2008 17:41:11 -0400
    From:        Taylor R Campbell <campbell%mumble.net@localhost>
    Message-ID:  <20081016214113.5D5F598284%pluto.mumble.net@localhost>

  | Since x11/libX11 happened to be built first into the chroot environment, it
  | installed inputproto-1.4.3.tgz, of which I already had a binary in my
  | local directory of binary packages.  The subsequent attempt to build
  | x11/modular-xorg-server failed because inputproto-1.4.3 was already
  | installed when x11/modular-xorg-server asked that inputproto-1.4.4 be
  | installed.

Been there, done that, don't wear T-shirts ...

My procedure (quite similar to yours) starts out by deleting (moving
actually, but the effect is the same) all binary packages that aren't
up to date.   In your example, the binary package for inputproto-1.4.3.tgz
would have no longer existed, forcing a recompile from source, which
would have installed 1.4.4 (or whatever later version is current).

Overall, this works quite well.   That is, provided the dependency info
in pkgsrc is properly maintained (see PR 39734 ... and in this message
I got it right!)

  | The second problem is that this process won't build newer versions of
  | some packages, if (1) I didn't have those packages installed,

I use lintpkgsrc -p to find what needs rebuilding, that finds all the
old binary packages (whether they happen to be installed or not).

The problem of packages getting built with different options being
indistinguishable in binary package form is one of the problems pkgsrc
eventually needs a solution to.

  | Possibly there are other ways to upgrade pkgsrc, but I'd like to
  | maintain the following criteria:
  | 
  | 1. that the process rebuild only those packages whose rebuilding is
  |    necessary, by using existing binary packages when their versions
  |    match pkgsrc's exactly;

I do that.

  | 2. that the whole process occur inside a chroot, so that my working
  |    system remains untouched, particularly if anything fails; and

I use pkg_comp too (even the lintpkgsrc runs in the chroot).

  | 3. that the process be incremental, so that if it fails halfway
  |    through after ten hours, I need not repeat those ten hours.

That's only partly possible - packages completely built are no problem,
but a failure 6 hours into an openoffice build (using pkg_comp which
always does "make clean" success or failure) is going to restart at the
beginning...

kre