Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?
On Wed, 2020-12-16 at 14:46 +0000, Matthew Vernon wrote:
Not is it straightforwardly clear that "alternative init systems"
should in fact be interpreted to mean "alternative init systems (but
not
sysvinit)".
The GR text mostly seems to talk about *exploring* alternatives;
continuing to maintain a 30 year old system doesn't really seem
explorative work to me? Even retiring sysvinit support completely
seems fine with the GR's text.
Besides preserving sysvinit in its current state (arguably not
exploration), not much else seems to happen with regard to alternatives
to systemd as far as I am aware?
For exploration, much less support is needed: to install systemd-sysv
you had to fight with dpkg to uninstall / keep away an essential
package (sysvinit) for several years or choose alternative routes (e.g.
specify init= on the kernel command-line); you might have needed to
write .service units yourself to start services using systemd's native
facilities instead of a (limited, but well-working) compatibility
layer. I still have some custom .service units for packages that don't
ship one themselves.
Arguably having to create "fake" packages using `equivs` or similar
tools to satisfy dependencies one would like to force to be avoided
would be comparable to having to remove essential packages?
Not having all packages ship a sysvinit script must also be more or
less expected: we have 250+ packages shipping .service files, but no
sysvinit scripts in current testing. I already filtered out any
packages shipping DBus .service files and some packages part of the
systemd/sysvinit implementation itself for this, but there are some
other false postives like .timer units with their associated .service
unit that have equivalent cronjobs (though some might miss a cronjob as
well). For comparison: 980 packages in total have any .service system
units and 1057 have a sysvinit script (excluding the packages part of
systemd/sysvinit itself.)
In addition some package use other systemd-provided facilities that
elogind conflicts with, e.g., systemd-tmpfiles; or systemd-hostnamed
here for NM (AFAIU).
As you already said you would like the technical committee to rule that
similar changes should not be blocked by maintainer of other packages
and already said you have some packages in mind, I think it would be
interesting to know which ones you are talking about. Would
maintainers have to accept patches stopping use of systemd-tmpfiles,
systemd-hostnamed, ...?
Ansgar
Reply to: