Bug#592610: Issue with note [3] in Policy ch. 7: Replaces without Breaks
Sean Whitton <spwhitton@spwhitton.name> writes:
> Note 3 says
> To see why Breaks is normally needed in addition to Replaces,
> consider the case of a file in the package foo being taken over by
> the package foo-data. Replaces will allow foo-data to be installed
> and take over that file. However, without Breaks, nothing requires
> foo to be upgraded to a newer version that knows it does not include
> that file and instead depends on foo-data. Nothing would prevent
> the new foo-data package from being installed and then removed,
> removing the file that it took over from foo. After that operation,
> the package manager would think the system was in a consistent
> state, but the foo package would be missing one of its files.
> This works for the foo/foo-data example in the text because these are
> implied to be tightly coupled packages. But sometimes you do want
> Replaces without Breaks, because the cost of Breaks is high.
> bin:git-debpush is taking over /usr/bin/git-deborig from devscripts.
> So devscripts is getting a "Recommends: git-debpush (>= 13.12)" and
> git-debpush is getting a "Replaces: devscripts (<< 2.25.18)".
> If we also add a Breaks, git-debpush won't be installable on older
> Debian releases. Currently dgit and git-debpush are installable and
> work all the way back to buster.
> devscripts doesn't hard-depend on the functionality in git-deborig.
> You can't even use it without installing some of devscript's Recommends,
> like with other things in devscripts. Therefore it wouldn't make sense
> to give up the high installability of git-debpush and trivial
> backportability of src:dgit just so that if someone decides to install
> devscripts and then install and remove git-debpush, they will be left
> without git-deborig.
> Ideally the text would reflect this but it's a significant task to work
> it in without adding too much length.
My first reaction is that this is a very specific situation that isn't
going to arise much, in part because devscripts is a rather unusual
package: It provides a ton of functionality, most of which is probably not
used by the typical person who installs it, and therefore the risk of a
package inconsistency where part of the package goes missing is not as
high for it.
I think the way to generalize this would be to say that Breaks may not be
desirable if all of the following apply:
1. The replaced functionality is not that important to the original
package, so the consequences of the described pattern that causes the
file to disappear won't affect many people.
2. Coinstallation of the two packages is important (in backports, for
instance).
3. Backporting of the package whose files are being replaced is not
desirable for some reason, even though backporting of the replacing
package *is* important.
This seems like an edge case, and the criteria for 1 are rather murky. The
package inconsistency that can be reached without Breaks bothers me, since
it's a sort of silent corruption in the sense that the contents of the
installed packages no longer represent the files present on the system.
That seems worth going to some effort to avoid, and I'm a bit worried
about people accepting that state too readily.
In other words, I agree with your conclusion that not using Breaks is fine
in this situation, and this is why Policy says "should" and not "must,"
but explaining the exception cases to the "should" is a bit tricky.
> I think many people in Debian mistakenly think you can't ever use
> Replaces without Breaks; there is a Salsa CI 'missing-breaks' check that
> enforces it that we are now having to disable for src:dgit.
I think the problem might be more that forgetting the Breaks is a really
common error because nothing in the packaging workflow makes you add it?
If you try to move the file without Replaces, installing the new package
fails and that's immediately obvious, but once you add the Replaces,
nothing makes you add the Breaks and the failure mode is pretty silent. So
I'm not sure it's that people think it's flatly disallowed as much as it's
a common error that's hard to notice.
I'm surprised that there's a special check for this instead of relying on
Lintian, though. I don't *think* it requires cross-package knowledge to
diagnose?
--
Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>
Reply to: