[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Proposal: Reaffirm our commitment to support portability and multiple implementations



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: