Re: make replace

[David Holland <dholland-pkgtech%netbsd.org@localhost>]

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
dholland%netbsd.org@localhost