On 07/08/2017 03:35 PM, Stephen Kitt wrote: > As I understand Policy in this case, I’m not convinced this is a violation. > lur-command.1.gz should never have been in liblur3; it should always have > been in libratbag-tools. I moved the file from liblur3 to libratbag-tools, and > added the appropriate Replaces relationship; but as I understand it, Breaks > isn’t needed because the upgrade doesn’t actually break liblur3.
It breaks anything assuming that a certain file exists if a certain (buggy) package version is installed. > Considering > the behaviour described in footnote 54 (53 doesn’t apply here AFAICT), I don’t > think there’s a problem: the old liblur3 does end up missing a file, but it’s > a file it doesn’t need and should never have had, so its disappearance > doesn’t cause any problems. "its disappearance doesn’t cause any problems" That's something very hard to teach some automated tools. These tools look for things that could be problematic (or become problematic at some point). What's the actual problem with adding the matching Breaks? That's just going to invalidate some version mixtures and downgrade paths that you don't want to support anyway. Andreas
