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