| 1 |
On Sun, Jul 25, 2021 at 8:39 PM Michael Orlitzky <mjo@g.o> wrote: |
| 2 |
> |
| 3 |
> This is indeed a bug, but not the ones that have been suggested. The |
| 4 |
> underlying problem is that the DJB programs (mail-mta/netqmail, but |
| 5 |
> also net-dns/djbdns, for example) require a particular service manager. |
| 6 |
|
| 7 |
Is it actually using daemontools as a service manager? I am not |
| 8 |
familiar enough with it to say. |
| 9 |
|
| 10 |
When I skimmed the daemontools wiki page I got the impression that it |
| 11 |
was intended to be used in conjunction with openrc. Or at least that |
| 12 |
is one way it can be used. Of course, if this is the case it |
| 13 |
shouldn't be in that virtual, or if it is then it should itself pull |
| 14 |
in openrc as a dependency (assuming it can't also be used with |
| 15 |
systemd). |
| 16 |
|
| 17 |
I'd have to spend a lot more time than I care to looking into |
| 18 |
daemontools to really comment on that. |
| 19 |
|
| 20 |
> When OpenRC is installed only as a side effect of being listed first in |
| 21 |
> virtual/service-manager, it becomes "redundant" after one of the DJB |
| 22 |
> programs pulls in daemontools, and portage will offer to remove OpenRC. |
| 23 |
|
| 24 |
So, if it is intended as a service manager, it really shouldn't list |
| 25 |
it as a dependency. After all, we don't go sticking |
| 26 |
openrc/systemd/runit in every package that provides configs for these. |
| 27 |
|
| 28 |
> We should have made them support OpenRC and systemd. |
| 29 |
|
| 30 |
Well, this at least is the subject of a Council decision: no package |
| 31 |
has to support ANY service manager, nor can package maintainers block |
| 32 |
adding support for service managers to a package. |
| 33 |
|
| 34 |
Obviously at this point most packages support openrc/systemd, but they |
| 35 |
aren't actually required to. |
| 36 |
|
| 37 |
> With all of that said, maybe in the Handbook we should tell OpenRC |
| 38 |
> users to "emerge openrc", in case some other not-mutually-exclusive |
| 39 |
> init system is ever pulled in by another program. |
| 40 |
|
| 41 |
So, packages shouldn't be pulling in service managers in general. |
| 42 |
That would be a bug if it is the case. If daemontools does things |
| 43 |
other than service management then it might not be an issue, but of |
| 44 |
course in that case we probably do need to be careful about treating |
| 45 |
it as a service manager automatically. |
| 46 |
|
| 47 |
If a package happens to only supply a systemd service unit then it |
| 48 |
shouldn't just pull in systemd because obviously anybody who uses the |
| 49 |
package must want to reconfigure their entire host... |
| 50 |
|
| 51 |
It isn't unheard of to have packages that happen to only support one |
| 52 |
service manager (though much less common now) - these pacakges should |
| 53 |
never just list that service manager as a dependency. After all, |
| 54 |
users can just add their own service units/init.d's/whatevers. |
| 55 |
|
| 56 |
I don't want to say that qmail shouldn't list daemontools without |
| 57 |
knowing more about the situation, but that is why I suggested talking |
| 58 |
to the maintainer as a first step... |
| 59 |
|
| 60 |
-- |
| 61 |
Rich |
Archives