make replace

[Dieter Baron <dillo%danbala.tuwien.ac.at@localhost>]

hi,

  The fundamental assumption of make replace and rolling replace is,
that temporary inconsistencies in the installed package tree are okay:
The user knows what he's doing, the problematic parts of the tree are
marked and there is a (semi)automated way to repair the tree.

  I hope we all agree that creating inconsistencies unknowingly and
without warnings (and markings) from the tools should not be allowed
by the tools.

  So, as the tools are improved to catch more and more cases that lead
to inconsistent trees, make replace will run into more and more
problems.

  For most packages, replacing them won't cause inconsistencies, even
a minor update to a shared library (e.g. glib2 2.20.0 to 2.20.1).

  Some examples where using 'make replace' will lead to inconsistent
trees, as food for discussion:

  1. Packages depending on particular versions of other packages for
     good reason which the updated package doesn't fulfill, e.g. perl
     modules using a different path in 5.10 than in 5.8, so they
     definitely won't work.  (Perl scripts, on the other hand, usually
     shouldn't include perl's buildlink3.mk and thus not inherit the
     upper bound.)

  2. Files moving between packages, e.g. tex-foo being split off from
     teTeX; here tex-foo needs to be installed as a dependency of an
     updated teTeX package, but would overwrite files of the existing
     teTeX package; or header files + libraries moving from gtk2 to
     glib2, where a newer glib2 would overwrite files from the old,
     still installed gtk2.

  3. A major version update of a shared library.  This does not cause
     an inconsistency yet (just broken dependencies), but will once we
     solve the open-ended dependency problem.

  Which raises the questions: What temporary inconsistencies do we
want to allow, how do we mark them, how do we handle them while
operating on an inconsistent tree, and how do we detect that the tree
is consistent again.


                                        yours,
                                    dillo & Thomas