Bug#851747: sysvinit-utils: drop Essential flag

Andreas Henriksson andreas at fatal.se
Tue Jan 28 13:52:33 GMT 2020


About a month ago (so I hope I remember all the details correctly) I got
motivated to revisit looking into this issue again.

My previous concern had been about how much work it would need because
of how widely used pidof is.

While actually looking closer at the users of pidof (using
codesearch.debian.net to search for 'pidof ') I found that most callers
where actually using 'if pidof ... ; then .... ; fi' and very few where
calling pidof in a way that would actually fail if the command where not
around. I also noticed that generally the (non-existant) "else" case
where to be considered the correct code path for pidof not being
installed in my opinion. The amount of packages actually needing pidof
to be around thus was much lower than I first anticipated.

Given that codesearch.debian.net would give source-code matches which
could very well not be shipped at all in the resulting binary packages
built from the source, I figured I'd set out to do some quick testing

I tried both 'debootstrap --variant=minbase' as well as a regular
'debootstrap' (including priority standard,important,required packages)
both with the --exclude=sysvinit-utils. Both worked as a charm and as I
see it proves that in theory the package being 'Essential: yes' is plain
wrong. Additionally I tried booting (using systemd-nspawn) the regular
chroot (with standard/important packages included) and could not spot
anything problematic despite missing sysvinit-utils package. That
probably points to the 'Priority: required' also being theoretically

As I see it a possible plan for moving this forward could be to start
off by dropping 'Essential: yes' (while still keeping 'Priority:
required'). This would mean sysvinit-utils where still installed
virtually everywhere (including 'debootstrap --variant=minbase'), while
opening up for allowing packages to declare a dependency on
sysvinit-utils where needed (without violating policy).

(I bet someone will argue that this causes a theoretical correctness
problem as some packages that should have a dependency lacks it. I would
however like to point out that it's a theoretical problem, not a
practical one as every installation will still have sysvinit-utils
installed. I'd also like to point out that the current state of things
already violates theoretical correctness as pointed out above. There's
thus no theoretical regression, just one theoretical problem replaced
with another - allowing to move forward and actually solving the
theoretical issues.)

This leads up to me wishing that people should tread carefully when
introducing dependencies on sysvinit-utils, mainly as I think long-term
we should switch to the procps implementation of pidof. Please urge
anyone adding a dependency on sysvinit-utils not to just document they
did so, but to clearly write down *why*.

I haven't spend enough thought on if it would be simpler to move pidof
from sysvinit-utils to procps at the same time or at a separate time. I
know from personal experience that getting maintainers to drop pointless
(build-)dependencies they've introduced in the past is close to
impossible, even when you prove it's not needed (and even when the dep
is on something that's going to get removed from the archive!). I think
most uses of pidof can and should likely be fixed up instead of adding a
dependency. For init scripts there's pidofproc in LSB for example.
Likely you could go even deeper and question why using that is needed.
You can likely get rid of that as well with a bigger
refactoring/modernization of the init script.
Once pidof is moved into procps, sysvinit should "obviously" gain a
transitional dependency on procps. This however would make a 'Priority:
required' package depend on a 'Priority: important' one (while no longer
being a policy violation in itself, I think it's still suboptimal to
make procps pseudo-required). This could be one reason why it would be
better to postpone transitioning pidof until we're ready to consider
downgrading sysvinit-utils to 'Priority: important' (or lower).

(If anyone has concerns about the pidof implementations possibly not
being 100% compatible, I'd just like to say that any such problem is
already a portability problem as anything that only works with the
sysvinit-utils pidof will not work on non-Debian distributions as
basically everyone is already using procps pidof. It should thus in my
opinion be fixed up in the caller.)

Andreas Henriksson

More information about the Debian-init-diversity mailing list