[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#592610: Issue with note [3] in Policy ch. 7: Replaces without Breaks



Hello,

On Wed 13 Aug 2025 at 12:00pm -07, Russ Allbery wrote:

> 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.

Thanks, I agree with everything you've written here.

>> 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.

Yeah, you're probably right.

> 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?

The check currently actually determines whether there are issues with
file overwriting, by installing the packages and seeing what happens, I
think.  But I don't know much about it.

-- 
Sean Whitton

Attachment: signature.asc
Description: PGP signature


Reply to: