[changed subject because I can't stand the old one] On Fri, Aug 09, 2019 at 08:46:18PM +0200, Simon Richter wrote: > I can totally see the benefit of using systemd unit files as init scripts > through start-stop-daemon, because we could have a common "open socket, > chroot, drop privileges" wrapper that way, most of the code is already > there (start-stop-daemon's command line is a descriptive interface) and it > would still be simple enough to fully understand in a single day. > > If I went and implemented the "API" by implementing all the features in the > man pages, I would indeed get the single property I like the least about > systemd: that its specification is always in flux. > > I am fairly sure it would be possible to define a more powerful API than > init scripts. Alas, that hasn't happened yet, because nobody is willing to > create a normative reference. Alternatively, we can decide on a subset of unit files that would cover the normal start-stop-daemon features, and like 80% of initscripts, and would be very unlikely to be changed anytime soon by systemd upstream, and decide that if that's all you need for your /etc/init.d script, you can just ship the unit file and delegate the sysvinit case to the start-stop-daemon equivalent. Those packages that use more unit file features can still ship an init.d script, but at least all those packages that just start/stop a service don't need to bother about maintaining yet another shellscript that bitrots dangerously over time. I even have a python implementation of most such unit file features that I can offer as a starting point, please give me a few days[1] to talk to one of my customers about putting it into a public git repo. Enrico [1] today's a national holiday in Italy: https://en.wikipedia.org/wiki/Ferragosto -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini <enrico@enricozini.org>
Attachment:
signature.asc
Description: PGP signature