Hi Michael, On Fri, Jul 18, 2014 at 08:06:11PM +0200, Michael Stapelberg wrote: > Gerrit Pape <p...@dbnbgs.smarden.org> writes: > > I'm really not keen to add a dependency to daemontools-run, esp. not to > > the runit package, just for (un)installing and starting/stopping a > > service. > I presume you mean init-system-helpers as the dependency you don???t want > to add.
Any dependency: $ apt-cache show runit |grep ^Depends $ apt-cache show daemontools-run |grep ^Depends Depends: daemontools (>> 1:0.76) $ apt-cache show daemontools |grep ^Depends Depends: libc6 (>= 2.7-1) $ > > Why isn't it as simple as installing the unit, and then?: > > > > systemd not installed || start service > It is as simple as that. deb-systemd-invoke supports policy-rc.d, > though, which your intended example (AIUI) does not. You???d make some > users really unhappy if you break policy-rc.d with your package. I don't think so. The daemontools-run and runit packages don't include init scripts. policy-rc.d never had an effect on them, so nothing will break. > > systemd not installed || have service started by default > When systemd is not installed, where does the logic for having the > service started by default come from? While the actually relevant part > of that is as simple as creating a symlink, there are some things make > this entire process more complicated. Some of them come from the fact I hope this "as simple as creating a symlink" works out. > that the enabled-state needs to be synchronized across init systems, > i.e. what you do in systemd should also work for the > sysvinit-fallback. This is not necessary for the packages in question. They have an inittab entry since many years SV:123456:respawn:/usr/sbin/runsvdir-start The whole purpose of the packages is to provide this service, no "enabled-state" is needed. $ apt-cache show runit |grep ^Description-en Description-en: system-wide service supervision $ apt-cache show daemontools-run |grep ^Description-en Description-en: daemontools service supervision $ > Further, consider this (from the manpage of deb-systemd-helper): > > The "enable" action will only be performed once (when first installing > the package). On the first "enable", an state file is created which > will be deleted upon "purge". > > ???which enables administrators to disable units and not have them > magically re-enabled on the next package upgrade. See above, I don't think this applies. > Also, the dh-systemd/deb-systemd-helper combination properly handles > mask-after-remove (i.e. remove but not purge). Anything wrong in this regard with my current implementation? > In general, it???s hugely beneficial to Debian if packages use the same > helpers/debhelper addons to build their maintainer scripts. Bugfixes and > other improvements that we put into i-s-h will propagate to all packages > without coordinating huge updates/fixes. You don???t need to think about > all the intricacies of correctly handling unit files (in Debian!) > because we already did it. We're different individuals in Debian and have different opinions. To me it's beneficial to Debian if there still exist packages not using debhelper, doing things differently than others, even than the masses, following KISS. I want to think about and understand how the inittab entry SV:123456:respawn:/usr/sbin/runsvdir-start translates most easily into a systemd service, now that I learned that this is necessary because systemd doesn't provide backward compatibility for such services. > Let me also point out that _every_ system already has i-s-h installed > these days, so there really is no cost in adding this dependency. That's not true. Just a few of my systems have this package pulled in, all of them have runit installed. Regards, Gerrit. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org