Re: new package pkg_rolling-replace

[Greg Troxel <gdt%ir.bbn.com@localhost>]

  Very nice!

Thanks.  Bug reports, fixes welcome.

  One question -- can it ever end up in a state where something doesn't
  build, making it stop and lose state about what else needs to be
  rebuilt?

It can easily end up stopped, and does so if any package operation
fails.  This happens to me all the time, when I have a bad distfile
due to download problem, or more often when a package has been renamed
or split into foo and foo-lib, and then foo wants to build foo-lib
which can't install because it conflicts with foo.

But, pkg_rolling-replace doesn't have a lot of internal state, and
rerunning it picks up where it left off.   There are several kinds of
state:

  which packages are "dirty", and that's a "pkg_admin set" variable
  'unsafe_depends'.  So not only does pkg_rolling-replace not need to
  store this, but you can do a manual make replace without breaking
  the invariant that a package is marked unsafe_depends if a
  dependency has been make replaced out from under it.

  manual rebuild requested, which is a "pkg_admin set" variable
  rebuild.

  packages that are 'mismatched' according to pkg_chk, which will just
  get recomputed if you do 'pkg_rolling-replace -u'

  dependencies.  These get observed from the installed packages, and
  then additional dependencies from each package to be built are
  pulled in via 'make show-depends' just before a package is 'make
  replaced'.  If any new ones appear, the dependency list is
  re-tsorted and a new package to replace is chosen.  This catches new
  dependencies in the source package, and build-only dependencies.
  Arguably pkg_rolling-replace should just do 'make show-depends' on
  each source package before starting out, but I don't think it
  matters in practice and in theory I'm not quite sure.

That's about it.  I sometimes need to run it 5 times to do a rebuild
of everything after a few months, but I just fix the reason it stopped
and rm all the work dirs and then run it again.


If you are comfortable doing make replace, and picking up the pieces
when you have a missing shlib, and working around build breaks, then
I'd say go right ahead and try pkg_rolling-replace.   I think you'll
find it easier than doing make replaces by hand, but it's still more
error prone than building everything you need in a chroot because it
doesn't solve the renamed/restructured package problem.