[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#639290: upgrade from squeeze to wheezy fails on i386 (pre-depends loop)



On Sun, Sep 4, 2011 at 17:14, Jonathan Nieder <jrnieder@gmail.com> wrote:
> David Kalnischkies wrote:
>
>> Would you be equally willing to unpack lets say bash without a
>> clear idea then you are able to configure it again [0]? (or X? APT? libc6?)
>
> Yes, I would.  Core packages continue to function when they have been
> configured before and are unpacked without deconfiguring.  Otherwise,
> the whole system would break unrecoverably during every upgrade in the
> unpack stage.

E: User worked with an embedded system too recently…
Sorry, in my eyes bash has lost it's essential status already.
Using it as my example wasn't that well chosen…

My point was that we have a lot of "core" packages which are not
really core but are so important that many people will not be able
to recover from a broken state with out those (and/or a lot of help).

APT for example (that it keeps working is because it treats itself special),
a texteditor or even something as simple as an internet connection…


> Which is not to say I dislike the idea of prioritizing the
> configuration of some packages!  Just that changing de facto policy
> like this without documenting it for packagers is not very pleasant.
> One way to fix that would be to write a patch for policy.

JFTR: There is no change, this behavior was included already in the
very first commit in the available vcs history (around 1998).
That this behavior is a problem is known since then (I assume it at
 least as it was an old bug at the time I joined three years ago…)
That the alternatives are worse in case of failure is known, too.

That it needed 13 years and a bit of money to motivate someone to really
work on it for the better part of 3 months might tell us something about
how many really care about programs they consider important through.

Anyway arguing with the policy is a bit strange as APT isn't violating
the policy by applying a stricter view by default on a problem.
The policy defines the minimum - that is relatively easy to implement.
The problem is through that every small packaging bug can bring you
into a completely broken system state then…


Best regards

David Kalnischkies



Reply to: