Response to active removal of initscripts

Tito farmatito at
Thu Jul 2 20:54:09 BST 2020

On 7/2/20 7:54 PM, Martin Steigerwald wrote:
> Dear Thorsen.
> No need to Cc me.
> Thorsten Glaser - 02.07.20, 19:19:58 CEST:
>> On Thu, 2 Jul 2020, Martin Steigerwald wrote:
>>> This does not sound good. It makes me want to switch of my last
>>> Debian based system to Devuan, unsubscribe from development related
>>> mailing
>> As if Devuan had the resources to survive a sysvinit removal from
>> Debian.
> Currently it is still there in most packages. It depends on how many 
> maintainer choose to remove init scripts, really.
>>> lists of the Debian project and probably even cease my little
>>> packaging effort I still do for Debian. Cause in the end I am
>>> seriously fed up with
>> Even if you only use a downstream, packaging should be done upstream.
> I get that. But I am fed up with it. Debian feels more and more hostile 
> to me.
>>> Debian. And this may be sooner than later if I see an update of
>>> Network Manager removing the init script here as well, cause I rely
>>> on its
>> This particular package is of no concern to me given I use ifupdown,
>> but others will follow its example…
> For KDE Plasma the package is important. Especially when it comes to ad 
> hoc WLAN connections without having to deal with WPA supplicant.
>>> I bet either someone musters up the courage to bring this up, again,
>>> on debian-devel or debian-project or so… I think there are quite
>>> some
>> The amount of people bringing it up is getting low, too.
> I may bring it up, once I braced myself for the s… storm to come then.
>>> Debian developers though who do not agree with removing init scripts
>>> like this.
>> Yes, but sheeple. Also, they might be more fed up with the
>> endless discussions…
> Then Void Linux might be an option.
>>> The other option would be to let the difference between Devuan and
>>> Debian become bigger and fork any package where the Debian
>>> maintainer removes a init script or something else required by
>>> other init systems.
>> As if…
> Again, if only just some Debian package maintainers behave in such a 
> way, it would probably not be too much of a problem for Devuan.
> That is basically one reason I still maintain fio. As long as I do it, 
> the init script I created for running fio in daemon mode will remain 
> there. I am also open to accept a runit service directory.
> Best,


I know nothing about debian packaging. That said you will excuse 
me if I say horribly stupid things.
Let us taken for granted that for the near future things will stay
the same and therefore more and more init-scripts will  be removed
from packages. What could be a viable solution besides forking
all this packages, a effort that could overwhelm devuan's manpower?
I would suggest creating a initscritps-extras package, where all
the orphaned init-scripts (and more..) could be collected with 
eventually needed support files (like those in /etc/default/).
Most of the scripts (if not all) have a test to check if the
daemon is installed e.g:

test -x "$MDADM" || exit 0

so they could not do any harm. The only problem I can think about
is that the user needs to run insserv manually to enable the script
in the various runlevels (but maybe this could be achieved automagically).

Just my 0,2 cents.


More information about the Debian-init-diversity mailing list