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
