| 1 |
On Sun, 2021-07-25 at 20:52 -0400, Rich Freeman wrote: |
| 2 |
> On Sun, Jul 25, 2021 at 8:39 PM Michael Orlitzky <mjo@g.o> wrote: |
| 3 |
> > |
| 4 |
> > This is indeed a bug, but not the ones that have been suggested. The |
| 5 |
> > underlying problem is that the DJB programs (mail-mta/netqmail, but |
| 6 |
> > also net-dns/djbdns, for example) require a particular service manager. |
| 7 |
> |
| 8 |
> Is it actually using daemontools as a service manager? I am not |
| 9 |
> familiar enough with it to say. |
| 10 |
> |
| 11 |
> When I skimmed the daemontools wiki page I got the impression that it |
| 12 |
> was intended to be used in conjunction with openrc. |
| 13 |
|
| 14 |
You start svscan (part of daemontools) with OpenRC, but then you do |
| 15 |
some other stuff to make svscan actually start the daemon. |
| 16 |
|
| 17 |
|
| 18 |
> So, if it is intended as a service manager, it really shouldn't list |
| 19 |
> it as a dependency. After all, we don't go sticking |
| 20 |
> openrc/systemd/runit in every package that provides configs for these. |
| 21 |
|
| 22 |
If a service manager is only needed to launch a daemon, then sure. But |
| 23 |
the <daemon>-conf setup programs for djbdns (I don't know about qmail) |
| 24 |
create scripts that run executables from daemontools. So unless those |
| 25 |
are rewritten or replaced, daemontools is actually needed at runtime. |
| 26 |
|
| 27 |
|
| 28 |
> |
| 29 |
> > We should have made them support OpenRC and systemd. |
| 30 |
> |
| 31 |
> Well, this at least is the subject of a Council decision: no package |
| 32 |
> has to support ANY service manager, nor can package maintainers block |
| 33 |
> adding support for service managers to a package. |
| 34 |
> |
| 35 |
|
| 36 |
It may be legal to ship a package that's useless out-of-the-box, but |
| 37 |
I'm gonna consider it a bug =) |
Archives