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