On Sun, Jul 25, 2021 at 8:39 PM Michael Orlitzky <m...@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
