Re: Proposal: Reaffirm our commitment to support portability and multiple implementations
- To: Adam Borowski <kilobyte@angband.pl>
- Cc: debian-vote@lists.debian.org, Guillem Jover <guillem@debian.org>
- Subject: Re: Proposal: Reaffirm our commitment to support portability and multiple implementations
- From: Russ Allbery <rra@debian.org>
- Date: Sat, 30 Nov 2019 17:14:47 -0800
- Message-id: <[🔎] 87tv6kaltk.fsf@hope.eyrie.org>
- In-reply-to: <20191130232439.GA24726@angband.pl> (Adam Borowski's message of "Sun, 1 Dec 2019 00:24:39 +0100")
- References: <20191130174627.GA19136@gaara.hadrons.org> <87blst6vqm.fsf@gag.com> <tsl7e3hrxfn.fsf@suchdamage.org> <20191130232439.GA24726@angband.pl>
Adam Borowski <kilobyte@angband.pl> writes:
> * request a list of non-systemd-hostile policies to be changed[4], initial
> contents being:
> • an unrelated package forcing an init switch on a straightforward apt
> invocation is RC-buggy (usually caused by an unthoughtful deps ordering)
For the record, I suspect we can get regular Policy consensus for this
rule, since having one's init system changed by installing some unrelated
package is clearly buggy.
> • requesting a redundant .service file when an init script exists, without
> a good reason (doubles work and reduces test coverage)
Note that the next revision of Policy will recommend that all packages
that want to start a daemon have systemd units because the generator that
handles init scripts has various undesirable edge cases. The systemd
behavior is generally better and more consistent if every service has a
unit file.
There were no objections during the Policy discussion process for this
change, for the record.
> • allowing unrelated packages to be unbuildable when a specific daemon/etc
> is installed (ie, should B-Dep/library-Dep on not-yet-existing
> systemd-dev instead of systemd, but the problem is not restricted to
> systemd)
Could you provide some more information about what your concern is here?
libsystemd-dev depends only on libsystemd0, which has a pretty tiny list
of dependencies and shouldn't require that systemd be running so far as I
know. Are you thinking of test suites that assume systemd is available?
--
Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>
Reply to: