Bug#938964: please don't install runit-helper on everyone's system

2021-10-09 Thread Lorenzo
Hi Noah,

On Wed, 4 Sep 2019 07:10:24 -0700 Noah Meyerhans 
wrote:

> 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

I'm looking for a way to fix all this kind of problems once for all.
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



Bug#938964: please don't install runit-helper on everyone's system

2019-09-07 Thread Dmitry Bogatov


[2019-09-04 07:10] Noah Meyerhans 
> On Sun, Sep 01, 2019 at 09:38:36PM +0800, Shengjing Zhu wrote:
> > > 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).
> > 
> > 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.

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

> 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.

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.

> 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.

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'm happy to create a separate bug for the filesystem issues if you'd
> like to track them separately from the package name issues.

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.
-- 
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.



Bug#938964: please don't install runit-helper on everyone's system

2019-09-04 Thread Dmitry Bogatov


[2019-09-01 21:38] Shengjing Zhu 
> On Sun, Sep 1, 2019 at 9:23 PM Dmitry Bogatov  wrote:
> > 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).
> I'm not sure why you didn't chose this at first. As it calls itself
> "helper tools for all init systems".

It calls, yeah.

Package: init-system-helpers
Maintainer: Debian systemd Maintainers 

-- 
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.



Bug#938964: please don't install runit-helper on everyone's system

2019-09-04 Thread Noah Meyerhans
On Sun, Sep 01, 2019 at 09:38:36PM +0800, Shengjing Zhu wrote:
> > 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).
> 
> 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



Bug#938964: please don't install runit-helper on everyone's system

2019-09-01 Thread Shengjing Zhu
On Sun, Sep 1, 2019 at 9:23 PM Dmitry Bogatov  wrote:
> 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).

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.

-- 
Shengjing Zhu



Bug#938964: please don't install runit-helper on everyone's system

2019-09-01 Thread Dmitry Bogatov


[2019-08-30 23:38] Shengjing Zhu 
> Package: runit-helper
> Version: 2.8.13.2
> Severity: normal
>
> Please, don't do that. Don't let it be a second libsystemd0.

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.


-- 
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.



Bug#938964: please don't install runit-helper on everyone's system

2019-08-30 Thread Shengjing Zhu
Package: runit-helper
Version: 2.8.13.2
Severity: normal

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

Thanks


signature.asc
Description: PGP signature