Bug#727680: “Yes, do as I say!“ sounds odd

[David Kalnischkies <kalnischkies+debian@gmail.com>]

[reordered to have the most-important response-part first]

On Sun, Oct 27, 2013 at 9:33 PM, Fabien Givors (Debian)
<f+debian@chezlefab.net> wrote:
> On 27/10/2013 18:54, David Kalnischkies wrote:
>> On Sun, Oct 27, 2013 at 2:55 PM, Fabien Givors (Debian)
>> <f+debian@chezlefab.net> wrote:
> I'm sure you have, as an apt dev, a better understanding than me of
> these problems so, now that I've reported my thoughts, I'll stop arguing
> and trust your decision :)

No no no no no. Put that idea back into the trash bin there it belongs.
Use a baseball bat if you have to, to keep it from popping up again! ;)

As a developer I have an incredible big bias because I know what the code
assumes. The result is that I don't see bugs anymore and understand the output
of apt even if it is in some foreign language which means that more often than
not the output *is* written in a foreign language nobody on this planet will
understand expect me [and the other core dev(s) maybe].


>>> --force-all does't only force removal of essential packages, but also
>>> AFAIK installation from untrusted sources, etc.
>>>
>>> More generally, I think that options like "--force-all" shouls /never/
>>> be recommanded as good practices. (Correct me if I'm wrong.)
>>
>> I agree, but I don't see how removing essentials could be interpreted as
>> "good practice"
> Well, replacing the (essential) init with a non-supported one looks to
> me like an operation that should be well supported by the package
> manager. The fact that everything may break after is not the
> responsibility on APT/DPKG anymore (and that's' to my understanding, the
> non-supported part.)
>
> Then using the "I'll do everything I can without checking anything"
> --force-yes option looks to me like "we don't support removing essential
> packages anymore".

Ah, now I see where are you coming from.

My take is: Removing an essential package is in the same category as
'rm -rf /'. Very few people will ever need it for what it does, but
many people (in comparison) will execute it by accident. rm invented
the --preserve-root flag, APT has this silly question (and a flag) and
starts to bug you to install this package again e.g. on dist-upgrade.
I feel like this is in line with what the debian policy says:
http://www.debian.org/doc/debian-policy/ch-binary.html#s3.8

So in the current init-limbo-state the flag being set on sysvinit is wrong
as the interface it provides is required, but not the actual implementation.
We have the same situation with awk which is (pseudo-)essential as a virtual
package with currently two different implementations.

What the essential flag is supposed to guard is better described by the
examples: dpkg, coreutils or findutils. Other packages assume they are
available for usage all the time. Its a bit of a stretch to say the same
about "init". A program doesn't really care who is his parent and isn't
interacting with it (I e.g. can't imagine a case in which it would be
 useful/legal to shutdown the machine from a maintainer script…)

Indeed, the various init system maintainers have it on their agenda to work
on this, not sure what the status of this is ATM though. I guess it is
pending on the decision if Debian actually wants to enable switching inits.
Currently, you are able to replace sysvinit with the competitors, but
assuming its decided to adopt one of the competitors you can't switch anymore
as the additional interfaces the new one provide become "essential" –
which are not provided by the other competitors as they are backward-
compatible to sysvinit, but none of them is forward-compatible to any
other init (at the moment).

So, the desire to remove an essential package and replacing it with another
package feels like a temporary glitch to me which is hopefully resolved
for good soon without involving APT.


Best regards

David Kalnischkies