[2019-08-27 16:35] Jan Braun <janbr...@gmx.de> > > > Personally, I'd prefer linking /etc/sv/foo/supervise to a place of my > > > choosing and expect that link to be preserved. Not sure how others > > > would feel, or how they'd try to deal with the issue. > > > > Why would you need it? Content of 'supervise' directory is transient, > > there is nothing valuable in it. > > Except the permissions, if non-default.
Okay. > > While I understand desire to make things as configurable as possible, it > > will put burden of /properly/ purging things from dpkg to me, which I'd > > rather avoid. > > Are you saying "me" as in the Debian maintianier of runit, or "me" as in > the local admin of the machine in question? As Debian maintainer. > When I add files in non-default locations, I expect dpkg/maintainer > scripts not to touch them, This. Maintainers scripts is my burden. > and possibly dpkg to message me "directory /some/path not empty, not > removed" when purging the package, alerting me that I might need to > clean up manually. I think that kind of behaviour is required by > debian policy, it has worked whenever I needed it in the past, and > AFAICT it works with the runit* packages right now. So there should be > no additional burden on you, the Debian maintainer. That is the point. dpkg manages files that are part of package (as of dpkg -L), that is why I want make /etc/sv/foo/service symlink part of package. If I create something in maintainer script, I have to purge it in maintainer script, with all kinds of interesting corner cases (e.g #848239 #848240) > If you meant the purging of /var/lib/runit/supervise/foo in case the > runit* packages decide to put things there by default, that's an > unconditional "rm -rf" in the appropriate maintainer script and not much > of a burden. Or am I missing something there? If admin put something valuable in /var/lib/runit/supervise/foo I have to re-implement (see runit-helper source) "directory not empty, not removing" logic. > As to where Debian's runit should point the symlink by default: > > /var/lib/runit/supervise/foo: > + persists non-default supervise dir permissions at no cost to the > local admin. > - unneccessarily persists the rest of the supervise dir. > /run/runit/supervise/foo: > - requires admin effort to get persistent non-default supervise dir > permissions. > + saves writes to a durable medium during operation. > > I don't really have a preference here. Thanks for this summary. I did not thought about saving writes. As I pointed above I have strong preference for /run/runit. Actually, I consider /var/lib/runit/supervise major design error of mine. > And I don't need to. :) Because on my machines, I'm back to a ramdisk on > /etc/service, which: > + persists exactly what it's told to (by placing it in /etc/sv ) > + saves writes to durable storage > - requires a reboot or other admin action to apply their /etc/sv > changes to the ramdisk. :( > > I doubt that's an acceptable default configuration for Debian, but it's > implemented as an option with very little effort: > * a few lines setting up the ramdisk in /etc/runit/2 (conditional on > /etc/service being a symlink to /run/service), > * a one-line change preventing /lib/runit/invoke-run from dying to > the changed path¹, > * a new script (or patch to update-service) to implement said > admin action without rebooting. > Holler if you're interested in adding it to Debian. (Which would be > nice, but I can live very well on my local modifications too.) Not sure > if having this as an option should tilt the /run vs. /var decision. While I see advantages of your setup, I am not ready to support it Debian-wide, in numerous Debian configurations. What I can offer is following: * I can bundle your /etc/runit/2 in /usr/share/doc/runit/contrib, with clear notice that this setup is not officially supported by Debian, but is succesfully used by some admins. * You can propose patch for update-service. As long it still work with default configuration and does not introduces too much complexity, I am okay to apply it. Lorenzo knows better about `update-service` than me. * You can file bug on `invoke-run`, we will see what can be amended. -- Note, that I send and fetch email in batch, once in a few days. Please, mention in body of your reply when you add or remove recepients.
