On Wed, 15 Nov 2017 16:50:22 +0100 Didier Kryn <k...@in2p3.fr> wrote:
> Le 15/11/2017 à 16:21, KatolaZ a écrit : > > On Wed, Nov 15, 2017 at 04:14:37PM +0100, John Hughes wrote: > >> On 15/11/17 15:30, Sam Protsenko wrote: > >>> Recently "libreswan" package was added to Debian: [1]. But it only > >>> contains systemd init script and lacks sysvinit script. > >>> Corresponding bug was reported to Debian bug tracking system: > >>> [2]. But libreswan maintainer refuses to include sysvinit script > >>> to his package > >> What Daniel Kahn Gillmor actually said was: > >> > >>> If anyone wants to propose specific patches to the debian > >>> packaging to either have the main libreswan package automatically > >>> support sysvinit (or any other initsystem) or produce a > >>> libreswan-sysvinit (or libreswan-runit, etc) binary package, and > >>> that the patch author volunteers to help test and maintain that > >>> system integration work over time, i'd be open to reviewing and > >>> incorporating reasonable changes into the debian packaging. > >> Which seems pretty reasonable to me. > >> > >> > > So it would be better if Sam Protsenko offered to help the Debian > > maintainer in including and testing the scripts for sysvinit. > > > Apparently Kahn Gillmor requires more: he requires the > commitment of a person as a quasi-maintainer to do the job of > maintaining the init scripts for the package on the long term. This > means Debian maintainers are no longer in charge of maintaining init > files other than systemd's. I doubt we could see one of these > maintainers accept to maintain sysvinit scripts and ask the users to > take care themself of maintaining systemd init files. > > Didier This situation is nothing unexpected. Many of us predicted in 2014 that Debian would continue throwing down all the anti-anti-systemd obstructionism they could muster. It would not be unreasonable to expect that the time will come where most Debian packages will fail to provide sysvinit scripts. If/when this time comes, we have several alternatives: 1) Help the Debian maintainers, as several have suggested in this thread. 2) Write our own sysvinit scripts, for Devuan only. 3) Write Process Supervisor scripts, and run daemons from a Process Supervisor. I personally don't like #1. The Debian maintainers are obstructionists, so I wouldn't help them: I wouldn't give them the sweat off my W*(#RF(#*. #2 is nice, helps give Devuan a unique brand, but IMHO making and maintaining a good-for-all-setups sysvinit script is difficult and time consuming. As a matter of fact, those horrible scripts necessary to cover most cases, is what made people furious at sysvinit in the first place: I don't think anyone cared about boot time or parallel instantiation. #3 is, in my opinion, practical. Any fool can write a run script with environment variables: Even I can do it. In most cases, a daemon doesn't care whether it's started by the main init system, or indirectly by a supervisor started by the main init system. Like #2, this helps give Devuan a unique brand. Also, this future-proofs us: When Debian drags their feet in putting forth a sysvinit init script, a Devuan volunteer can step forward with a supervisor run script. Over a period of time, more and more daemons in Devuan could be run from a single supervisor process. So then the question becomes, what supervisor? Runit? S6? Daemontools-encore? Perp? I'd rule out daemontools-encore for the simple reason that it can never take on the entire role of init. For whatever reason, Perp is unknown, with very little mindshare, so I'd temporarily rule that out. Runit and s6 are both extremely well thought of, can both be turned into complete init systems. The combination of a sysvinit PID1 plus a spawned supervisor can make Devuan capable of running lots of daemons abandoned by Debian, for years to come. SteveT Steve Litt November 2017 featured book: Troubleshooting: Just the Facts http://www.troubleshooters.com/tjust _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
