retitle 1037496 show note about missing boot integration for non-systemd
thanks
Hi Mark,
On 6/13/23 14:28, Mark Hindley wrote:
> It would be a great help to users of non-systemd inits if you could restore
> them.
thanks you for your report.
Personally I'm using systemd, but in general I fully agree that as long
as it's no "burden" to keep the sysvinit scripts around, I'd keep them.
For mdadm specifically, using sysvinit scripts has been the source of a
bunch of bugs as some things are not properly supportable when it comes
to events/race-condition handling when detecting raid devices in early boot.
Most other distributions as well as upstream don't support sysvinit
anymore in mdadm. I can see at least three disadvantages for keeping
sysvinit scripts in mdadm around:
* I would need to support them in Debian for a type of system I
don't use anywhere anymore since several Debian releases.
Personally, I'd rather spend time on, to me, more appealing things.
* Keeping sysvinit support for mdadm in Debian de-facto makes me
upstream for these scripts, which doesn't seem right given that
I don't use it myself.
* Keeping sysvinit support would "falsly advertise" that it's actually
maintained and cared for, which isn't the case and I'd expect that
a lot of bugs don't get spottet in time for a next Debian release.
As of policy 4.5.0, including sysvinit scripts in a package if systemd
units are present, is not longer recommended but optional, so that (at
least after the bookworm release last weekend) I'd expect that a lot of
other packages are going to drop the sysvinit scripts too.
A solution could be for those that like to keep using sysvinit, to
submit the scripts for inclusion in the orphan-sysvinit-scripts package
and maintain it there.
> Installing recent mdadm on a non-systemd system can render the system
> unbootable.
Good point, I'll think about emitting an appropriate message so that
it's not easily overseen in such situtations.
Regards,
Daniel
