Re: [gentoo-user] --depclean wants to remove openrc. Yikes!

[Rich Freeman <rich0@gentoo.org>]

On Sun, Jul 25, 2021 at 8:39 PM Michael Orlitzky <mjo@gentoo.org> wrote:
>
> This is indeed a bug, but not the ones that have been suggested. The
> underlying problem is that the DJB programs (mail-mta/netqmail, but
> also net-dns/djbdns, for example) require a particular service manager.

Is it actually using daemontools as a service manager?  I am not
familiar enough with it to say.

When I skimmed the daemontools wiki page I got the impression that it
was intended to be used in conjunction with openrc.  Or at least that
is one way it can be used.  Of course, if this is the case it
shouldn't be in that virtual, or if it is then it should itself pull
in openrc as a dependency (assuming it can't also be used with
systemd).

I'd have to spend a lot more time than I care to looking into
daemontools to really comment on that.

> When OpenRC is installed only as a side effect of being listed first in
> virtual/service-manager, it becomes "redundant" after one of the DJB
> programs pulls in daemontools, and portage will offer to remove OpenRC.

So, if it is intended as a service manager, it really shouldn't list
it as a dependency.  After all, we don't go sticking
openrc/systemd/runit in every package that provides configs for these.

> We should have made them support OpenRC and systemd.

Well, this at least is the subject of a Council decision: no package
has to support ANY service manager, nor can package maintainers block
adding support for service managers to a package.

Obviously at this point most packages support openrc/systemd, but they
aren't actually required to.

> With all of that said, maybe in the Handbook we should tell OpenRC
> users to "emerge openrc", in case some other not-mutually-exclusive
> init system is ever pulled in by another program.

So, packages shouldn't be pulling in service managers in general.
That would be a bug if it is the case.  If daemontools does things
other than service management then it might not be an issue, but of
course in that case we probably do need to be careful about treating
it as a service manager automatically.

If a package happens to only supply a systemd service unit then it
shouldn't just pull in systemd because obviously anybody who uses the
package must want to reconfigure their entire host...

It isn't unheard of to have packages that happen to only support one
service manager (though much less common now) - these pacakges should
never just list that service manager as a dependency.  After all,
users can just add their own service units/init.d's/whatevers.

I don't want to say that qmail shouldn't list daemontools without
knowing more about the situation, but that is why I suggested talking
to the maintainer as a first step...

-- 
Rich