[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
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
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
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.
dillo & Thomas
Main Index |
Thread Index |