"Bernhard R. Link" <[EMAIL PROTECTED]> writes:
> * Daniel Burrows <[EMAIL PROTECTED]> [050112 22:08]:
>> Well, you're also leaving the package in a broken and unconfigured state.
>> Doing this in order to save the user a little typing later (adding the
>> original package to the second --install line) seems to me like a hack to
>> make some use cases slightly more convenient, not elegance.
>
> The elegance is that dpkg is robust in that it can always install
> everything and can get cleanly from one state to another. However broken
> the packages are you never end in a sitation you cannot fix again.
> The additional checks suggested here add some additional term of
> "correctness", that dpkg has to check on the resulting state. Without
> some full formalisation or anything else to make sure it cannot get out
> of this state, or can get back to that state easily, it is only a hack.
> It would also break serialisation, as one would need to give a list of
> packages to install to dpkg all at once or in the correct serialisation,
> and no longer (with exception of configure cycles) beeing able to give
> them in whatever sequence as one is pleased to do.
All that is asked is for dpkg -i to do a simulation of unpack, then
check the configure checks and report errors before doing the actual
unpack and configure. That doesn't change the serialisation or
argument reordering dpkg might do internally.
> Hochachtungsvoll,
> Bernhard R. Link
MfG
Goswin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
