Breaking init swtich: was Re: sysvinit_3.14-2_source.changes ACCEPTED into experimental

[Andrew Bower]

Hi Mark,

On Sun, Feb 23, 2025 at 09:06:43AM +0000, Mark Hindley wrote:
> So it is still possible to switch. Views may differ as to if this is too
> difficult or dangerous. My personal gut feeling is that switching init on a
> system is a rare occurence, so the extra dpkg --force-remove-protected step
> isn't a great overhead. Also, people do not wish to discover their init has been
> changed 'incidentally' by apt. But I would appreciate hearing other
> perspectives.

I think there's a difference between having to do some deliberate step
and having to deploy some esoteric invocations that make it look like
what you're doing is probably rather flaky...

I am conflicted on this.

Yesterday I almost accidentally switched away from runit on a crucial
upgraded Devuan Stable box because I tried to upgrade sysv-rc-conf and 
https://salsa.debian.org/debian/sysv-rc-conf/-/commit/9f7f669ae18c5d37a5d95f25de72b3b7ef7069ad
had, needlessly in my view, made the package depend on sysv-init-core.
Your change would have prevented this.

But it's already hard to switch to runit on Debian. Going via sysvinit
is usually the way I do it.

It doesn't seem fair to make it harder to switch to runit without also
resolving https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1006971
("add runit-init as a Pre-Depends of init metapackag [tracker]").

Perhaps we could muster some support here to help Lorenzo get this over
the line? He has done so much to tick the boxes laid out for runit to
qualify!

> I also see a possible small benefit.  If individual packages to declared they
> 
>  Provides: init
>  Protected: yes
> 
> the contentious init package could disappear and alternative inits would not
> need to convince the systemd maintainers that they achieve whatever standard.

Is this a realistic possibility?