Re: make replace

[Dieter Baron <dillo%danbala.tuwien.ac.at@localhost>]

On Jul 6, 2010, at 0:04, David Holland wrote:

> On Mon, Jul 05, 2010 at 03:23:42PM +0200, Dieter Baron wrote:
>>  Which raises the questions: What temporary inconsistencies do we
>> want to allow, 
> 
> ...any?
> 
> 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?

  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).

  As the tools are improved to handle more complex tasks (like updating a set 
of packages, and figuring out what needs to be done to get to a consistent 
state with the new packages), they will rely on more consistency constraints.  
So, if you want the tools to deal gracefully with the temporary inconsistencies 
pkg_rr introduces, these inconsistencies need to be well defined.

> 
>> how do we mark them, 
> 
> Same as we already do; maybe we need multiple strengths of unsafe
> depends, but that's a fairly minor issue.

  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?

>> 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.

yours,
dillo