Re: Policy consensus on transition when removing initscripts.
Hi,
On 6/29/23 01:56, Sam Hartman wrote:
Russ> This feels like exactly the kind of problem that normally
Russ> Debian goes to some lengths to avoid creating, but it sounds
Russ> like several commenters here don't think the effort is worth
Russ> it?
Normally, Debian spends a fair bit of effort to avoid these kind of
breakages.
But I think init systems other than systemd are in kind of a special case.
I agree, but it doesn't make a difference anyway.
The init scripts are conffiles. Dpkg should not remove them on upgrade,
so no such window exists, unless maintainers explicitly remove these
files, which would be "deleting user data" and therefore wrong, except
in very specific cases.
Longer term, we might either want to also develop a strategy to remove
these files, or decide to not bother because the impact is minimal,
especially without the compatibility layer and with immutable images.
It also seems a bit strange to require more from the maintainer when
they are dropping an init script than we would if a maintainer started
depending on a feature like socket activation such that their packkage
simply would not work without systemd.
This would be a case where the init script and the systemd unit deviate
in functionality. I don't see a problem with that, and my expectation is
generally that the people running sysvinit and the people running
systemd have different expectations here anyway.
Very few services depend on systemd and are completely unable to manage
their own listener sockets, and those that do never had an init script
in the first place and are not in use on any machine not running
systemd, so there is no regression.
In general, the sysvinit crowd prefers "traditional" Unix daemons, many
of which also exist on BSD, so these are unlikely to lose the ability to
work outside the systemd environment.
Simon
Reply to: