[Pkg-sysvinit-devel] Bug#805487: Intent to NMU sysvinit, init-system-helpers.

[Andreas Henriksson]

Hello!

I think the current state of the previously announced sysvinit[0] and
init-system-helpers[1] branches should now be in decent shape to
upload this to the archive. Partially motivated by the recently
announced "If you are hoping to do any larger changes for stretch,
please consider starting on them now"[2].
I'm thus announcing my intent to NMU, please speak up now if you
have any objections...

As I see it init-system-helpers have given their acknowledgement
for NMU based on previous comment from Michael Biebl on this bug
report and the just now ack and support from Martin Pitt on IRC.

Some areas for further work has been identified:

1. Investigate priorities

With the new (Pre-)Depends introduced in
http://anonscm.debian.org/cgit/collab-maint/sysvinit.git/commit/?h=wip/init-tools&id=e5cd50029f4a1dedfd4810474ce40b106cd9a322
we now have priority required packages depending on init-system-helpers
which currently has priority extra.

The easy solution here to stay policy compliant would be to bump
init-system-helpers to Priority required, but at the same time
there's atleast ideas to make init systems non-essential (and
lower their priority?) for the benefit of containers. Maybe
the long-term solution is instead to lower sysvinit-utils
(atleast/definitely!) and sysv-rc priorities instead....

This is the only real potential blocker right now as I see it.
Likely going for the short-term solution and just bumping
init-system-helpers to required will be implemented now to
avoid blocking on this. Priorities could be lowered once
sysv* priorities potentially are in the future...

2. reassign bugs + review patches

Once init-system-helpers ships the tools the open bug reports
should ofcourse get reassigned. There seems to be a number of
bug reports with patches attached. I think it's better to
not entangle the moving the files with introducing potential
new functionality, so better we do this later IMHO.


3. file-rc integration

It once upon a time seems to have been the recommended practise
to fork update-rc.d instead of integrating with it which seems
to be what file-rc has done. Then came upstart and systemd which
integrated their support into the sysvinit version of update-rc.d,
which starts the question if file-rc shouldn't do the same now?!

Either way the integration of file-rc needs to somehow be fixed
because the current conflict/replaces will not work in the future
because of several reasons.

Given the extremely low and declining popcon[3] of file-rc I'm not very
interested in working on it myself. I've asked Michael Prokop (file-rc
comaint) about the state of file-rc related to my changes and he
indicated that grml still uses file-rc and had not yet finished its
planned switch to systemd. I did not hear any major objections to
proceeding so I assume that by the time Stretch is ready for release
grml will have finished their move to systemd (if it hasn't already).

I see things like grml a reason to do the changes *now* rather
than later in the strech development timeframe. This will give
time for any issues to not only be identified but hopefully also
time for people to deal with chain effects.

Regards,
Andreas Henriksson


[0]: http://anonscm.debian.org/cgit/collab-maint/sysvinit.git/log/?h=wip/init-tools
[1]: http://anonscm.debian.org/cgit/collab-maint/init-system-helpers.git/log/?h=wip/init-tools
[2]: https://lists.debian.org/debian-devel-announce/2016/01/msg00000.html
[3]: https://qa.debian.org/popcon.php?package=file-rc