As I have mentioned, I tried adapting userv to systemd and upstart. I have already reported on my experience with the core daemon code.
In this message I'll deal with the config fragments ("units" and "jobs" as they call them), and the Debian-specific packaging. I'm treating the config fragments as part of the packaging, rather than as something upstreamish, because in practice they are inherently un-debuggable without access to a system running the corresponding daemon. They are also small enough that any distro which cares could easily ship their own (and might need to). I found configuring upstart to be utterly trivial. There was little opportunity for error. More guidance in debian-policy would be a good idea, including perhaps a reference to some example packages. The machinery neeeded in the package was also trivial. For userv, I didn't need to modify the maintainer scripts at all; the existing invocations of update-rc.d and invoke-rc.d DTRT. (userv is an old package whose packaging predates debhelper, let alone dh(1).) I had to add a new call to dh_installinit and drop the upstart job file in the correct location. Debugging things was also very easy. The logfiles were where I expected they would be and had the expected contents. I have read the documentation for the socket activation approach. Inevitably this would be a bit more fiddly but it seems like it would have been nearly as simple. systemd was rather more complex. There was less support from the Debian policy manual. Perhaps there is some other systemd Debian packaging guidance somewhere which I didn't find. The unit files were somewhat harder to write. It wasn't just that the systemd unit file offered a great many more options, although that was a factor. The two-unit split of systemd socket activation was more fiddly. And systemd wants each directive to be in a particular "[section]". The package maintainer scripts exposed more complexity too. It was necessary to add new systemd-specific calls to "deb-systemd-helper". The boilerplate required here was too much to simply include in my existing scripts, so I had to switch the package to using debhelper-generated maintainer scripts. (This is of course a good idea in the long run, but it would be better to require less yak-shaving.) Part of this complication results from systemd's curious approach to deciding which services need to run in which runlevel (or equivalent): once again we are expected to drop some symlinks into a magic directory - and provided with semiautomatic utilities for doing this. Also, the approach to the systemd integration introduces a new runtime package dependency on "init-system-helpers", which despite its generic-sounding name actually contains only helpers for systemd and is maintained in Debian by the systemd maintainers. Perhaps it would be possible to have more sophisticated maint script fragments which will cope if deb-systemd-helper is not installed - but, then, of course, the systemd maint script fragments will be even more complicated. I'm not sure at the moment whether I want to ship the systemd integration in my package :-/. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org