On Thu, Nov 19, 2020 at 09:04:07AM +0000, Matthew Vernon wrote: > [I don't need a CC, thanks] > Hi, > > > I know it was mentioned back in the day, but trying to re-ask it now: > > Wouldn't it be possible to ship init scripts for compatibility purposes > > from a sysvinit (or maybe a sysvinit-support) package? This would be the > > inverse of what happened back when systemd was introduced, which was > > about shipping service files that superseded existing init scripts. > > I have thought about this, and it seems like a bad idea for a number of > reasons, including: > > 1) poor user experience - a package of initscripts would clutter > /etc/init.d/ with a huge number of files (most of which would be no use to > the user)
This could be fairly easily fixed. Option one: - Don't install the init scripts in /etc/init.d, but install them in /usr/share somewhere. - Install a dpkg trigger that uses ucf to copy the relevant init scripts /etc/init.d (and goes through the rest of the dance to enable them) when the relevant package(s) is/are installed. Option two: split up the initscripts package into multiple smaller packages. I don't think either of these are necessary, but if it's a concern, there are ways. > 2) init scripts to need to change sometimes, typically that change will > accompany a version change in the associated daemon (e.g. the CLI changes) - > the most natural way to have this work seamlessly is for the init script to > come with the daemon This puts the burden of maintaining said init script on the maintainer. In my reading of the GR, that's not expected of maintainers anymore. I think it's fair for a maintainer to be expected to file a bug on an "init scripts" package if their CLI changes. The rest should then be the job of the maintainers of that init scripts package. > 3) many upstreams (esp. those who support BSD) ship a sysvinit file, again > making the daemon (source at least) package the natural place to keep it. Yes, but does this also apply to network manager? > 4) difficulty reliably achieving seamless handoff from daemon package to a > putative sysvinit-scripts package (e.g. packages that actively remove the > init.d file from the installed system; keeping a users' modifications to the > file) This might need some dependency trickery that I don't immediately have a good answer for, but that I don't see as insurmountable. Furthermore, it is my belief that if you are not running the default init system, that then *some* level of ugliness is to be expected. At the very least, you'd see systemd units on the file system that you're not ever going to be using. I think it's unreasonable to expect the same level of cleanliness and technical excellence as when your preferred init system was still the Debian default. > > I understand that you might not want that maintenance burden, however it > > seems like the network-manager maintainers might not want that > > maintenance burden either. > > I think the burden concern is over-made here. This is not a case of "this > init script has bugs that have been causing problems and no-one has fixed > it", nor a bug report of the form "please write an init script". There is an > extant, working init script. Software changes. Environments change. Sometimes an init script stops working due to changes outside the maintainer's area of responsibility. This has happened to the nbd-client init script at one point, for example (no bug, because I found it out myself and fixed it, but it did happen). Thus, maintaining an init script that the maintainer themselves doesn't want to use or think is useful, imposes a burden of *at least* testing it on the maintainer, for which they need a separate system (or, at least, a VM) in order to do proper testing of the package with all that implies. That's actually quite a bit of work, and it's not unfair that the maintainer wouldn't want to do it. If the init script is in the network-manager package, then the maintainer is at the very least *expected* to make sure it keeps working. If it stops working, where is the maintainer going to ask for help? There is no guaranteed answer for the maintainer, and nothing they can do other than accept bugs against their package that they then have to set up a wholly separate system for just so they can fix a bug they don't want to deal with in the first place. If the init script is in a separate package, then the maintainer can certainly give a heads-up to the maintainers of the separate package when something changes in network-manager. It would not be unreasonable to expect the network-manager maintainer to maintain a level of communication with the maintainers of said initscripts package, and I think you would have a *much* stronger case for complaining about maintainers not wanting to support your pet project. > There are people more than happy to provide assistance should it need > updating. I concede that collaborating with those people is non-zero > effort, but this is not a case of "I want this work done and am not > prepared to help do it". The help is there now. Will it still be there when there is an RC bug in the network-manager script two weeks before the freeze and there are 27 other similar bugs? Note that I'm not saying this is absolutely going to happen, but it is not unreasonable for a maintainer to be worried about things outside their control. When the init script is in a separate package rather than in the network-manager package itself, then it is not something for them to worry about anymore. -- To the thief who stole my anti-depressants: I hope you're happy -- seen somewhere on the Internet on a photo of a billboard
signature.asc
Description: PGP signature
