First, a horror story, then the moral and an idea.

The last two days I thought I'd do a simple thing: get rid of the
not-really installed copy of ncurses 4.2 I had around (as far as the pkg
tools thought) in favour of the 5.0 version I really had.

So I did a make update in pkgsrc/misc/dialog - it was the only thing
that really used it. Unfortunately, this caused an unexpected avalanche
of work: eventually over half my files in /usr/pkg/bin got deinstalled
and rebuilt! (about 388, and that does not count the ones in
/usr/X11R6/bin such as mozilla) It took the best part of two days to
rebuild them all... On the plus side: this whole ordeal, however long it
took, worked without a hitch...

What happened is approximately this: an update always starts with
pkg_delete -r, which deletes a package and everything that depends on
it. So the following were blown away (modulo version numbers
- these are the versions after rebuilding):

    teTeX-bin-1.0.7nb1
    teTeX-1.0.7
    lyx-1.1.6

All of these depend (among other things) on png, and it turned out there
was a new version of it. There went

    netpbm-9.7
    imlib-1.9.8.1
    gnome-libs-1.2.8
    gdk-pixbuf-0.9.0nb2
    control-center-1.2.2
    xscreensaver-gnome-3.28
    gdk-pixbuf-gnome-0.9.0nb2
    gnome-core-1.2.4
    gmc-4.5.51
    gnapster-1.4.2
    mozilla-0.8
    ghostscript-6.01
    gv-3.5.8

These are not the smallest packges..  Here and there some other new
versions have sneaked in as well that I hardly even noticed anymore.

At the end, dialog didn't even depend on ncurses anymore...

So I think this is all a bit too much. After all, why should teTeX be
removed if I'm just going to replace /usr/pkg/bin/dialog with a (not
even newer!) version that is compatible enough? We're not forcing a
complete system recompilation if somebody installs a newer gcc..

I think there should be a "lazy-update" method. 

- static libraries: these can even be completely removed without any
  dependent packages being affected, so a lazy update is always
  possible.
- shared libraries: these can be removed too apart from sometimes the
  actual .so file.  Header files can be removed as in the static case.
  For minor number upgrades, the old .so.x.y can be removed, for major
  number upgrades the old .so.x.y file needs to be kept but nothing
  else. Therefore, a lazy update is always possible.
- executables: this is more subtle. Updating for instance perl from
  5.00404 to 5.6 does not need to change anything that uses perl scripts
  - the language is compatible. Only perl extensions need to be
  recompiled (if they have a compiled component - otherwise they also
  can be kept). But I think a lazy update is usually possible.
  Sometimes a package changes so much that is significantly incompatible
  with a previous version - this could be recorded in the package's
  Makefile and if the installed package is older than the indicated
  version, the lazy-update would not be available.

Unfortunately, this cannot simply be implemented by not-deinstalling and
then useing FORCE_PKG_REGISTER when reinstalling. That might leave some
stray files. But blindly removing all files with pkg_delete -f may
remove too much in the shared-library case. So it is slightly more
complex than that, but not much more I think.

I shudder at the thought of updating to perl-5.6 without a lazy update
method... 

Thoughts?

-Olaf.
-- 
___ Olaf 'Rhialto' Seibert - rhialto@polder --Soep van de dag, wat zal dat zijn
\X/ land.nl     --wat kan dat wezen, beter maar het ergste vrezen -Boy Bensdorp