Le samedi 19 août 2023 à 20:58 +0200, Helmut Grohne a écrit : > Control: reopen -1 > Control: found -1 mathcomp-analysis/0.6.4-2 > > On Sat, Aug 19, 2023 at 05:33:11PM +0000, Debian Bug Tracking System > wrote: > > It has been closed by Debian FTP Masters > > <ftpmas...@ftp-master.debian.org> (reply to Julien Puydt > > <jpu...@debian.org>). > > I'm sorry. Adding Breaks is necessary but insufficient. You also need > Replaces.
What is in libcoq-mathcomp-analysis << 0.6.4 is now in two packages: - libcoq-mathcomp-classical (a small part) ; - libcoq-mathcomp-analysis (the most part -- and that binary package depends on libcoq-mathcomp-classical with a strong version constraint). The problem you pointed was that a user with an old libcoq-mathcomp- analysis asking to install libcoq-mathcomp-classical would lead dpkg to a conflict of files. The breaks I added prevents that, and in fact a user with an old licoq-mathcomp-analysis should have no issue in those situations: (1) try to install a newer libcoq-mathcomp-classical -- with my Breaks dpkg will refuse because of the conflict which is a sane answer : system not broken, features not broken ; (2) try to upgrade - dpkg will see the new libcoq-mathcomp-analysis needs libcoq-mathcomp-classical and that it breaks the outgoing libcoq- mathcomp-analysis, but it's able to handle the situation ; If I declare libcoq-mathcomp-classical Replaces libcoq-mathcomp- analysis << 0.6.4, then in situation (1), dpkg will install libcoq- mathcomp-classical and drop that old libcoq-mathcomp-analysis. The system is not broken, but the user just lost most of the functionality, and that is bad. So I think the change I made is sound. Do you have another problem in mind? Or a better fix? Cheers, J.Puydt
