Re: Package not compatible with old systemd
On Wed, 2018-09-19 at 10:07 +0200, Wouter Verhelst wrote:
> On Tue, Sep 18, 2018 at 10:45:45AM +0200, Ondrej Novy wrote:
> > for example when files are overwritten. This is not case and Breaks
> > "is enough".
>
> "Breaks" means "will cause the other package to fail". That isn't the
> case here. Additionally, Breaks isn't supported very well by some
> tools, so it's better to be avoided.
It is usally recommended to avoid Conflicts in favor of Breaks: Policy
says "Normally, Breaks should be used instead of Conflicts"[1].
[1] <https://www.debian.org/doc/debian-policy/ch-relationships.html#conflicting-binary-packages-conflicts>
> "Conflicts" *can* mean "shares pathnames with other package", but it
> doesn't have to; it can also mean "doesn't work well with other
> package".
Policy specifically says to use Breaks in this case: "Breaks should be
used [...] when the breaking package exposes a bug in or interacts
badly with particular versions of the broken package." (same section as
above)
> You're claiming that the systemd support of your package won't work
> correctly unless you have a particular version of systemd on your
> system. If that's the case, then you should Depend on the correct
> version of systemd. If you also support other init systems, you can
> add
> an alternate dependency on those other systems; or you can use
> Recommends: rather than Depends: if you don't want it to be absolute.
Depending on an init system is definitely wrong as it is perfectly fine
to use some service without any init, such as in Docker containers, or
under other supervisors such as runit.
Ansgar
Reply to: