Le mercredi 23 août 2023 à 09:07 +0100, Simon McVittie a écrit : > 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.
I'll just fix the bug like you want to avoid blocking other packages, but I really do not understand, so I'll continue asking on the debian- policy bug to get things clarified. Cheers, J.Puydt
