Hi Simon,
On Tue, Aug 11, 2026 at 03:13:43PM +0200, Simon Josefsson wrote:
> Isn't this report a fall-out after fixing
> https://bugs.debian.org/1143626 and that everything will be fine as soon
> as 3.5.6-2 enters testing?
It is fine if you assume that nobody ever installed knot-doc/3.5.6-1.
However, that version was part of forky. Once 3.5.6-2 migrated, forky
users could run into this upgrade running a testing to testing upgrade
procedure.
It also can be experienced by unstable users upgrading there, but for
unstable users we somewhat expect that users can resolve this (e.g. by
temporarily removing knot-doc).
> Mutual installability mixing packages from unstable and testing is not
> supported, right?
Technically speaking you're right and this has not been rc bug. It
became an rc bug the exact moment the package migrated to forky. Of
course we would like to not increase the rc bug count in forky. Hence me
filing it as a migration blocker in unstable.
> The 3.5.6-2 version seems to already be in testing, even though the PTS
> 'news' section doesn't have any entry for testing migration.
If you were to fix it right now, it would take another two days for the
fix to reach forky. By that time, the majority of users will have
upgraded and run into the bug (if applicable). So it is indeed
questionable whether fixing it now is worth the effort. I argue that it
would have helped if testing migration were prevented. So I leave it up
to you whether to fix or to close without further action.
> Alas, package versioning, file conflicts and upgrade issues usually make
> my head hurt, and I wish there were more tooling around to detect and
> regression check these issues. I guess what I'm looking for is a recipe
> to reproduce the file conflict error in some supported environment. Or
> better: a suggestion how to untangle the situation from where we are
> now.
I agree that the tooling is less than ideal. Actually, that's what I'm
working on. My filing of these bugs serves a dual purpose. For one
thing, I report bugs, but for another I gain more experience with what
kinds of issues exist. It turns out that a significant fraction of these
issues require further communication (including this one).
A general rule of thumb: If you move a file from one binary package to
a differently named package without changing the name of the file, the
new package has to declare versioned Breaks and Replaces against the old
package. The version should be the first version missing the file in the
old package with a tilde ("~") appended.
Evidently, remembering this rule is difficult when moving a file. Yet,
following it would have prevented both bugs.
Helmut
