Bug#932704: debian-policy: Don't force sysvinit compatibility if e.g. alternate init required

[Sean Whitton <spwhitton@spwhitton.name>]

Hello,

On Mon 22 Jul 2019 at 01:39pm +02, Ansgar wrote:

> On Mon, 2019-07-22 at 12:01 +0100, Sean Whitton wrote:
>
> What sort of dependencies are we talking about? Package-level
> dependencies (e.g. Depends: systemd-sysv directly or indirectly)?
>
>> People who don't like systemd have been working to provide replacements
>> for these hard dependencies.  E.g. there is elogind so that packages
>> which depend on logind can work on a sysvinit system.
>>
>> We would want to be careful to word this requirement such that it did
>> not license maintainers to do things which block the work of those who
>> don't like systemd.
>
> How would this "block the work of those who don't like systemd"?
>
> We do not have a requirement to ship systemd .service units, but that
> doesn't seem to have blocked anyone from submitting patches adding
> those.  It seems reasonable it would work the same for other init
> systems.

If a package depends on some systemd component which has been
reimplemented not to depend on systemd (e.g. logind and elogind), it is
my understanding of David's intent that this newly proposed exception
would not apply.  If the alternative implementation exists then the
package does not depend on an alternative init system, and so the policy
requirement to provide a sysvinit script remains in place.

I think that the wording for this change should reflect the above
(unless I've misunderstood David), such that the new wording cannot be
misinterpreted to mean that the sysvinit requirement does not apply to
any package using any systemd component.

-- 
Sean Whitton