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 _______________________________________________ Pkg-sysvinit-devel mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-sysvinit-devel
