On Wed, Aug 02, 2023 at 08:23:43PM +0000, Manfred Wassmann via Dng wrote:
>
>The real incentive to have the original scripts under /usr/share is that in
>Unixland /etc is for files edited by the system administrator and files
>(non-binaries) installed from a software package which are not intended to
>be modified go into /usr/share. You can find that mentioned somewhere in
>the Debian guidelines for the filesystem layout. Now having the original
>scripts under /usr/share/runit/sv and copied to /etc/sv allows the package
>to install new scripts into /usr/share/runit/sv without overwriting local
>changes made under /etc/sv.

If /etc/sv/<service>/run etc. is in the conffiles list, then local changes
won't get overwritten. At package upgrades you get prompted via debconf and
you can compare your local version with the package maintainer's one to see if
it needs to be updated (if you decide to keep your own, you'll still have the
package one there with a .dpkg-dist extension for reference). Actually the
only package on my system that comes with a runit service - openssh-server -
does this: it puts its files under /etc/sv, and they are marked as conffiles.

Which brings us to the more compelling argument put forward by aitor in the
other email: the package itself might provide a conflicting service under
/etc/sv. Now we are in the realm of policy decisions. Who should drive the
system startup, management of services and so on? Is it 1) the packages of
services themselves, or 2) a dedicated package that knows about all the
services.

Normally the answer would be #1 (this is how it works with sysvinit) as the
package maintainer is the one who knows best how to start up the service, what
configuration options should be available etc. However, with everything moving
towards systemd it is an unrealistic expectation that this would work out for
any other init system. So we need to fall back to #2.

Accepting a mix of the two in the hope that some package maintainers might
create runit scripts makes things much more complicated for very little
benefit. Just take a look at /lib/runit/trigger_sv. It's not a script you
would understand in a couple of minutes.

If there are potential conflicts, my opinion is that the dedicated package
should win by moving away everything else (with dpkg-divert?). And the maintainer
of the service should be persuaded to contribute to the dedicated package
instead.

Best Regards,
Lehel