[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: make replace
On Tue, Jul 06, 2010 at 03:07:10PM +0200, Dieter Baron wrote:
> > I can't think of there being any good reason to say "No, you can't do
> > that, you must remove everything related right this instant just in
> > case you lose your mind and forget to finish your update."
> How about "No, you can't do that, it would break your package
> database so badly the tools won't be able to operate on it any
> longer." Does it still sound like a reasonable thing to allow
> users to do, encourage them to do even?
No. That way, it sounds like a bug in the package tools.
> The package tools rely on the consistency of the installed
> packages and their metadata. So, "allow any inconsistency" is not
> a goal we can support in the tools (unless you count erroring out
> (or crashing) as support).
The package tools merely rely on being able to describe the installed
packages. "Consistency" in the sense you're referring to is
irrelevant -- the package database is consistent if the tools have
updated it correctly, regardless of whether it might describe a
partially updated system.
> That works for "the dependency constraints of this package may
> not be fulfilled". So are these the only sort of inconsistencies
> we want to allow?
Those are the only (new) concerns anyone has aired, including (as best
I recall) your mail at the root of this particular thread.
> >> how do we handle them while operating on an inconsistent tree,
> > What sorts of issues are you thinking of?
> See above. More specifically, when we start treating the
> installed packages as a set, and try to convert that set into
> another (updated or expanded) consistent set, we may very well run
> into troubles when the original set is inconsistent to begin with.
...that just means the model isn't good enough.
David A. Holland
Main Index |
Thread Index |