Bug#851747: sysvinit-utils: drop Essential flag

Andreas Henriksson andreas at fatal.se
Tue Jan 28 16:29:44 GMT 2020

Hi Michael,

On Tue, Jan 28, 2020 at 04:38:36PM +0100, Michael Biebl wrote:
> Hi Andreas,
> thanks for your interest in this topic.

Thanks for your interest in my interest. :)
Always nice with some feedback.

> Aside from /bin/pidof, we also have

... a bunch of niche tools that has been discussed before.
I haven't really looked at these recently but I guess not
much has changed, except maybe init-d-script has gotten
a bit wider usage. Will try to give some kind of updated
status for these below...

> /sbin/fstab-decode

Still only 2 users found by codesearch: drbl, open-iscsi

> /sbin/killall5

Still very few users. The following codesearch hits seemed somewhat
relevant to investigate:
util-vserver, apcupsd, lxc-templates (likely not shipped),
drbl, rear

> I haven't checked codesearch if those binaries are used outside of
> sysvinit/initscripts. Have you investigated those recently?
> And there is also
> /lib/init/init-d-script

In the past this had few users. These days I'd say the better fix than
adding sysvinit-utils dependency is to just require users of
init-d-script to also ship a masking native systemd unit.

There are 73 total hits for init-d-script on codesearch (including
false positives like lintian), so certainly still manageable.

> /lib/init/vars.sh

>From random samples this seems exctusively used from init scripts (and
examples of init scripts), so I'd say a masking native systemd unit
would be my preferable fix (rather than a sysvinit-utils dependency).

There are 280 codesearch hits.

> Those are the more tricky ones. A lot of init scripts use them.
> Not having those installed will render the init scripts of packages
> broken. It's less of an issue, if a package ships a native service file.
> (Do we know for how many this is the case, i.e. no .service file, SysV
> init script using init-d-script and/or vars.sh?)

(I just have to start by saying, dropping 'Essential: yes' doesn't mean
people will stop having sysvinit-utils installed. The literal definition
of 'Priority: required' is that your system will break if you remove
this package. I guess you're thinking ahead of potential future lowering
the priority....)

I haven't investigated how many of the init-d-script and vars.sh issues
are already solved. I'll however volunteer to look all of the affected
packages over (and hopefully submit patches for them) once the
'Essential: yes' bit is dropped.

(I'll *not* look them over before 'Essential: yes' is dropped, simply
because that's alot of work that will rot and will have to be redone
again and again and again. So just a waste of my time.)

> Also, we have /etc/init.d/foo → redirection to systemctl broken unless
> /lib/lsb/init-functions is the first thing that is sourced.
> Maybe that breakage is acceptable? Dunno.
> What are your thoughts here?

I think at as time goes by assuming people being used to init scripts
rather than systemctl/service commands becomes less and less true.
I might be to progressive but I'd say we're now at a point where
it's not very important to keep shielding the users from mistakes
like directly invoking an init script. While many oldtimers could
likely spell out the full /etc/init.d/foo path of a number of important
services in their sleep, I also think there's a whole generation of
people around now that administer systems without knowing what
/etc/init.d does at all.

> Given the size of the sysvinit-utils package, last time I looked into
> this I concluded it's probably not worth the trouble. But maybe things
> have changed by now.

I agree with this, but the reason I'm here again is because I've managed
to tick off most of the issues which had higher payoff already.
It's this one and #833256 (where I'd make the new packages non-essential
in the same go) left from my old investigations.... then there are the
"legendary" ideas that is as insane/unrealistic amount of work like
getting bash or perl out of the base. (But the value is not very high
there either, so I'd say it's even less worth to work on that than
Then there's things that might really painful (if at all possible) but
more rewarding, like shrinking the largest packages in the base system:
e.g. coreutils.

While size is one factor, I think getting rid of essential where not
needed has value in that dependencies can actually be properly
declared/tracked. For all the normal reasons in debian why being
able to track the dependencies is good, there's also likely value
in bootstrapping as well as more easily being able to build custom
minimal systems.

Andreas Henriksson

More information about the Debian-init-diversity mailing list