portmaster -R (Was: Re: HEADS-UP: Shared Library Versions bumped...)

[Ben Morrow]

Quoth Doug Barton <dougb at FreeBSD.org>:
> 
> How about this? When the user has -[rf] but not -R, and there are flag
> files present, ask if they should be cleared before beginning to do
> anything. Otherwise (no -[rf]) ignore them. Sound good?

Since my machine has spent the last 48hrs or so rebuilding everything
that depended on jpeg-6b and python25 (it's a pretty old machine), I've
been wondering if an option to say '*don't* rewrite the dependencies of
other ports to refer to the new version' would be a good solution here.

Normally this is a helpful thing to do, but when you're trying to
reinstall a few ports low in the dependency chain and then rebuild
everything that needs rebuilding it would be helpful to have the ones
that haven't been rebuilt still depend on the old (now deleted) package,
so they can be identified.

-r (and -Rr) don't help here, since lots of large ports depend on *both*
jpeg and python, and I was specifically trying to avoid rebuilding them
all twice. AFAICT -r doesn't allow you to ask for two ports plus all
combined dependants at once. I ended up taking the pkg_info -R list for
both pkgs before the upgrade, sorting it into dependency order, and
stripping entries off the front every time something failed and I had to
restart, which is a little too manual for my taste :). (The list had to
be sorted, otherwise port A might depend on port B that came later in
the list, and when portmaster got to B in the list it would reinstall it
again unnecessarily.)

It also occurs to me that this could be completely automated if ports
had a LAST_COMPATIBLE_VER field or some such, which tells you whether or
not an upgrade-in-place is safe. portmaster could even ask 'you've just
upgraded from foo-1.2 to foo-2.1 which is not compatible: do you want to
rebuild <list of pkgs> which depended on the old version?'.

Ben