Re: If we're Going to Have Alternate Init Systems, we need to Understand Apt Dependencies
Hi,
On Wed, Dec 04, 2019 at 04:43:39PM +0100, Ansgar wrote:
> For one of the problems (apt making unexpected decisions) that is
> pretty close to what is the case. We do find such issues again and
> again, including too late, i.e. only after a stable release, also for
> other packages that aren't related to init systems.
The experience is the same on the other side of the pond.
I think the problem is the transition process that forces us to make
dependencies weaker than they should be to have a satisfactory result.
One of the options I had in my original proposal was that we could drop the
requirement for transitions through apt, and instead provide transition
scripts that use dpkg's --force options to go through an invalid state
instead of requiring all intermediate states to be valid.
> In this discussion I provided a popcon graph which shows that systemd-
> shim has significantly more installations than sysvinit-core; if you
> prefer inline numbers: for stretch there are 3335 systemd-shim
> installations and 775 sysvinit-core installations. So it looks like
> something isn't quite as wanted. (And likely not all 775 sysvinit-core
> installations even have systemd-shim, so the unwanted case is even a
> bit larger; I'm too lazy to check that right now.) But even getting
> some people to acknowledge this seems very hard.
Could these be upstart based? IIRC installing systemd-sysv should deinstall
systemd-shim, so the obvious broken configuration is locked out.
> I also tried some related things, including some proposals to improve
> systemd support via Policy proposals that don't even degrade support
> for sysvinit such as recommending to always include native systemd
> units where approporiate. That now went back to someone questioning
> whether one should recommend to (almost) *never* include native systemd
> units instead...
I'd be in favour of always including units along with init scripts, ideally
as a strong requirement so we can disable the init script compatibility
layer in systemd, and the same for cron files and timer units.
Guaranteeing that the system will only ever consume one of the two files
would allow us to drop a lot of ugly hacks in individual packages, but at
the price of a big ugly hack in the compatibility generators (which we
still need to provide for users who want to run non-Debian software).
Simon
Reply to: