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