Re: If we're Going to Have Alternate Init Systems, we need to Understand Apt Dependencies
Hi Sam,
On Mon, 2019-12-02 at 15:25 -0500, Sam Hartman wrote:
> > > > > > "Ansgar" == Ansgar <ansgar@43-1.org> writes:
>
> Ansgar> Adam Borowski writes:
> >> * dependencies on "systemd | other" rather than "other |
> >> systemd"; this is a no-op on a systemd system (installed by
> >> debootstrap before any non-base packages) but causes apt to force
> >> an init+rc switch elsewhere
>
> Ansgar> It's very likely not a no-op on systemd systems as
> Ansgar> significantly more people somehow got systemd-shim installed
> Ansgar> than had sysvinit-core, see for example [1] which shows that
> Ansgar> somehow the "no-op" results in systemd-shim getting
> Ansgar> installed (which caused problems in the past).
>
> Ansgar> Just because you don't observe unwanted behavior happening
> Ansgar> right now on your system doesn't imply it doesn't exist.
> Ansgar> And the unwanted behavior that you say wouldn't happen (as
> Ansgar> it is supposedly a "no-op") happens on a scale larger than
> Ansgar> the entire sysvinit user base here...
>
> Ansgar, you keep bringing this issue up.
Yes, I bring this up as at is one of the few concrete examples where we
have alternatives that must be chosen at build time. I would like to
see if the proposed resolution would help if similar issues would come
up again.
> And it keeps coming up as "Stuff might happen that we don't really
> understand."
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.
> That's deeply unsatisfying to hear.
> And I think it's deeply unsatisfying to you when you hear that people
> talk about playing alternative games and assuming it's just going to
> work out.
Yes, I now understand that the proponent of proposal D would just
dismiss concerns as "theoretical degradations" without even trying to
understand the problem or even getting to a point where one would look
at weighting different trade-offs to get a compromise solution.
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.
Please note there was also a tech-ctte bug about the "no-op" dependency
on "systemd-shim | systemd-sysv" causing problems beyond theoretical
degradations previously (#883573).
But still this is given as an example of "changes I view as done with
spite, which bring no or negligible benefit to systemd yet large
detriment to other rc systems"[1].
So I believe proposal D wouldn't help with resolving conflicts at all
and doesn't provide improvements on this front.
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...
That is not very motivating and I fear that proposal D will result in
that happening for any "non-init-related declarative systemd facility"
as well. That is no improvement over the status quo, but additional
obstacles such as mandatory waiting times.
The "being excellent to each other" part of the proposal also leaves a
sour impression if the proponent doesn't seem interested to hold
himself to his own requirements as you pointed out in [2] (and other
people did so before), but asks these to be uphold by others.
Altogether this convinced me to likely rate "D" and some other choices
below "FD". I don't think they'll bring us forward, even if on paper
they might look like they do. That's a change from my position in the
2014 GR where I ranked the option that included "Debian packages may
require a specific init system [...] if [...] and no patches or other
derived works exist in order to support other init systems in such a
way to render software usable to the same extent" first (but which was
defeated by the option having less requirements to not provide support
for sysvinit).
Ansgar
[1]: https://lists.debian.org/debian-vote/2019/11/msg00386.html
[2]: https://lists.debian.org/debian-vote/2019/12/msg00064.html
Reply to: