On Wed, 23 Aug 2023 at 08:41:44 +0200, julien.pu...@gmail.com wrote:
> let's lower the severity to avoid blocking migration during the
> discussion -- after all the Breaks already avoids the file conflict
> issue.
Sorry, no, it does not. What Helmut said looks correct.
The Breaks prevents apt from installing the new libcoq-mathcomp-classical
without also upgrading or deconfiguring libcoq-mathcomp-analysis, but
does not constrain the order in which apt/dpkg will carry out the upgrade.
If they happen to have chosen this order of operations, which is what
happened when I tried an upgrade from bookworm to sid, and presumably
also what you saw in your own testing:
1. unpack the new libcoq-mathcomp-analysis
(leaving its dependency on libcoq-mathcomp-classical temporarily
unsatisfied - the overall state of the system is "partially broken")
2. unpack the new libcoq-mathcomp-classical
3. configure libcoq-mathcomp-classical
4. configure libcoq-mathcomp-analysis
(the system is back to a consistent state)
then the file-overwrite will be avoided. But if it chooses this order
of operations:
1. temporarily mark the old libcoq-mathcomp-analysis as deconfigured
(again, the overall state of the system is "partially broken")
2. unpack the new libcoq-mathcomp-classical
3. unpack the new libcoq-mathcomp-analysis
4. configure libcoq-mathcomp-classical
5. configure libcoq-mathcomp-analysis
(the system is back to a consistent state)
then step 2 is going to fail, because the old libcoq-mathcomp-analysis
contained files also present in the new libcoq-mathcomp-classical.
(Symptom: "trying to overwrite x, which is also in package y")
With the current metadata, there is no guarantee which of those
two upgrade sequences apt will choose. It is common for bugs of this
category to not happen during the maintainer's testing, but then be easily
reproducible by other users who have more/different packages installed,
which makes apt choose a slightly different upgrade path.
smcv
