Unfortunately, the whole of the following mail is based on a flawed
There is also no reason or basis for a virtual witch hunt in pkgsrc by
hunting down mythical problems with "inconsistent trees". I have no
idea why such a thing would be wanted. Ever.
Dear Al, I do not appreciate your polemic. Thomas, JÃrg and I *do* see problems with inconsistent trees, and I'm trying to lead a techincal discussion as to which balance to strike. On the one side is pkg_rr and temporary inconsistency while updating, on the other is preventing users from unintentionally (and unknowingly) breaking their installed packages and smartrr updates/installs.
David and your stance seem to be "I'll do whatever I feel like, and the package tools better deal with the fallout." I don't think this is constructive, nor do I think it is needed to accomodate pkg_rr.
I think the package tools should be smarter in handling installation of dependencies and updates, figuring out beforehand if the desired result can be accomplished, rather than installing a bunch of packages and then erroring out because a conflict arose. These kind of operations have to consider the installed package tree as a whole (or at least a subtree thereof), and thus have a legitmate desire for consistency constraints on the trees they have to operate on.
What I am trying to figure out is which inconsistencies are needed to accomodate pkg_rr.
We've managed to last for 13 years in pkgsrc without this kind of police
state, and we don't want it now. In the same way that we have managed
to limp along for upwards of 10 years with our versioning scheme and
not have a single case of the dreaded "open ended dependency" problem.
It bit us with perl 5.10, which we fixed with a special solution (which was easy, because it was easy to predict when the next incompatible update will be). Retroactively closing the open upper bound would help us say when a ceetain version of a dependency will not work with this package, due to shared library major bumps or other incompatibilities. Yes, we've "limped along" without it; however, what's bad about having that capability?
Please remember that the philosophy behind any tool is to do one thing
well. trying to accomplish too much will lead to pain, problems and
lack of use, or circumventions, workarounds and disuse.
True. But so will acomplishing too little. In my opinion, doing package installs well means telling me it won't work early before installing a lot of stuff. It also means chosing, amog multiple available versions of a package, the one that will lead to a successful install of the package I asked for.
Do you disagree with this goal?
Best regards,AlistairOn Mon, Jul 05, 2010 at 03:23:42PM +0200, Dieter Baron wrote:
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