Please, don't do that. Don't let it be a second libsystemd0.

Thanks

[2019-08-30 23:38] Shengjing Zhu <zhsj@debian.org>

Well, I am not happy with this situation myself too, but I do not know
do it better.

`runit-helper` is essentially dynamically-linked maintainer script. I
can easily put its content directly into maintainer script, and it will
even solve some problems,  but it will introduce new one: every change
to what is now `runit-helper` would cause transistion. Was there, did
that.

I thought about dpkg triggers, but there is no reasonable way to convey
required information to it. Also, triggers are meant to be idempotent,
while `runit-helper' is not -- it must enable service on first
installation, but must respect admin decision to disable it.

Just for my curiosity (not going to happen in my watch), would you be
happier if `runit-helper` script was part of init-system-helpers (which
is essential, anyway).

Another option I can propose is making call to `runit-helper`
conditional, so you can dpkg-exclude whole `runit-helper` package.

I'm not sure why you didn't chose this at first. As it calls itself
"helper tools for all init systems".
I'm not saying I'm happy with init-system-helpers, but this already
exists for long and looks better.

I think unifying the functionality of this package with
init-system-helpers would be preferable. But beyond just polluting the
package namespace, I'm a bit annoyed by the stuff that this package
leaves around the filesystem as well. In particular, /var/log/runit
shouldn't exist on systems that don't even have runit installed.
/etc/runit is similarly annoying.

I think it'd be worthwhile to come up with a slightly more sophisticated
mechanism for populating runit configuration on systems that actually
need such configuration, while also eliminating noise on systems that
don't need it. I'm happy to create a separate bug for the filesystem
issues if you'd like to track them separately from the package name
issues.

noah

[2019-09-01 21:38] Shengjing Zhu <zhsj@debian.org>

It calls, yeah.

	Package: init-system-helpers
	Maintainer: Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>

[2019-09-04 07:10] Noah Meyerhans <noahm@debian.org>

Only if you (or someone else) volonteer to be the ambassador.

If it does not clean after purge -- please report. It is important bug.

But otherwise, sorry, Debian is not Gentoo. We do have useless
files, packages, directories and even shared libraries around. This is
how things always were. E.g:

 * /etc/init.d/*
 * /etc/systemd
 * /var/lib/systemd
 * udev
 * libsystemd0
 * libselinux
 * apparmor
 * libblkid
 * doc-base

Well, maybe you are using some (or even most) of these, but it is not
the point. Wait, you can't use both apparmor and selinux.

This configuration system already exists, and is not tied to runit in
any way. It is called `dpkg --exclude`. So much on unwanted /etc/*
files.

But on package dependencies, you can't just remove `runit-helper` due
hard dependency, that is true. I find it (unlike files in /etc) real
problem. But I do not know solution.

I can relax relation to recommends, and change maintainer script to use
`runit-helper` only if it is installed. In such case, everything will be
fine as long as you do not try to boot with init=/lib/runit/runit-init
(or install runit-init).

And if you do, whether things will work out-of-box or you will end only
with tty1-6 depends on whether `runit-helper` was present when you
installed your services. Actually, it can be something in between.

I hope to reduce amount of code in `runit-helper`, so eventually it can
be reasonably embedded directly into maintainer script. But not today.

I am fine discussing it here.

By the way, initially I wanted to ship runscripts for services in
separate packages. This approach was reject by both FTP masters and
discussion on `debian-devel'. Somewhy there is strong opposition to tiny
packages.

Given this and establilished practice of including both systemd service
files and sysvinit init scripts (mandated by Policy) into main package,
I was given no choice.

In ideal world, there would be {foo}-bin, {foo}-systemd, {foo}-sysvinit,
{foo}-run and metapackage {foo}, that depends on everything mentioned
before. Unlikely to happen.

Hi Noah,
Please look at #942053 and #935939: if you have additional complains
open a separate bug against dh-runit package and list all the filesystem issues there.

Regards,
Lorenzo

"downgrade Depends: runit-helper to Recommends: runit-helper" or
"merge runit-helper into init-system-helpers".
*I* don't care about a few extra files in /etc.

For the record,
here's exactly how to do the dpkg excludes Dmitry mentioned.

On a full system, put this into /etc/dpkg/dpkg.cfg:

    path-exclude=/etc/sv
    path-exclude=/etc/sv/*
    path-exclude=/etc/runit
    path-exclude=/etc/runit/*

Before:

    bash5$ mmdebstrap forky /dev/null --quiet --include=openssh-server \
               --customize-hook='env --chdir $1 find etc/ -path "*sv*" -ls , -path "*runit*" -ls'
       316703      0 drwxr-xr-x   3 root     root           60 Sep  3 12:35 etc/sv
       316704      0 drwxr-xr-x   4 root     root          120 Sep  3 12:35 etc/sv/ssh
       316710      4 -rwxr-xr-x   1 root     root          393 Aug 24 02:39 etc/sv/ssh/run
       316707      4 -rwxr-xr-x   1 root     root          470 Aug 24 02:39 etc/sv/ssh/finish
       316708      0 drwxr-xr-x   2 root     root           60 Sep  3 12:35 etc/sv/ssh/log
       316709      4 -rwxr-xr-x   1 root     root          140 Aug 24 02:39 etc/sv/ssh/log/run
       316705      0 drwxr-xr-x   2 root     root           60 Sep  3 12:35 etc/sv/ssh/.meta
       316706      0 -rw-r--r--   1 root     root            0 Aug 24 02:39 etc/sv/ssh/.meta/installed
       316698      0 drwxr-xr-x   3 root     root           60 Sep  3 12:35 etc/runit
       316699      0 drwxr-xr-x   3 root     root           60 Sep  3 12:35 etc/runit/runsvdir
       316699      0 drwxr-xr-x   3 root     root           60 Sep  3 12:35 etc/runit/runsvdir
       316700      0 drwxr-xr-x   2 root     root           40 Aug 24 02:39 etc/runit/runsvdir/default
       316700      0 drwxr-xr-x   2 root     root           40 Aug 24 02:39 etc/runit/runsvdir/default
       306840      4 -rw-r--r--   1 root     root          367 Jul  1 14:45 etc/bindresvport.blacklist
       317112      0 lrwxrwxrwx   1 root     root           31 Jul 27 20:11 etc/alternatives/view.sv.1.gz -> /usr/share/man/sv/man1/vim.1.gz
       317089      0 lrwxrwxrwx   1 root     root           31 Jul 27 20:11 etc/alternatives/vi.sv.1.gz -> /usr/share/man/sv/man1/vim.1.gz
       317063      0 lrwxrwxrwx   1 root     root           31 Jul 27 20:11 etc/alternatives/ex.sv.1.gz -> /usr/share/man/sv/man1/vim.1.gz

After:

    bash5$ mmdebstrap forky /dev/null --quiet --include=openssh-server \
               --customize-hook='env --chdir $1 find etc/ -path "*sv*" -ls , -path "*runit*" -ls' \
               --dpkgopt='
    path-exclude=/etc/sv
    path-exclude=/etc/sv/*
    path-exclude=/etc/runit
    path-exclude=/etc/runit/*'
       320929      4 -rw-r--r--   1 root     root          367 Jul  1 14:45 etc/bindresvport.blacklist
       331190      0 lrwxrwxrwx   1 root     root           31 Jul 27 20:11 etc/alternatives/view.sv.1.gz -> /usr/share/man/sv/man1/vim.1.gz
       331167      0 lrwxrwxrwx   1 root     root           31 Jul 27 20:11 etc/alternatives/vi.sv.1.gz -> /usr/share/man/sv/man1/vim.1.gz
       331141      0 lrwxrwxrwx   1 root     root           31 Jul 27 20:11 etc/alternatives/ex.sv.1.gz -> /usr/share/man/sv/man1/vim.1.gz

You have to do the both subdir glob and the dir, or dpkg itself gets upset.
For a more complicated real-world example, see package "localepurge".

Many postinsts break if you path-exclude aggressively, but runit-helper seems OK.
I think maintainers are NOT REQUIRED to handle sysadmins doing arbitrary path-excludes.
I think maintainers are REQUIRED to handle sysadmins doing a few specific path-excludes, like /usr/share/doc/*.
I could not find a citation in https://salsa.debian.org/dbnpolicy/policy :-(

Packages installed before dpkg.cfg are edited don't "see" the exclusion immediately.
You have to reinstall/upgrade the packages.
There is a quality-of-life bug to fix this:
https://bugs.debian.org/603700