Le 19/08/2023 à 21:25, julien.pu...@gmail.com a écrit :
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).
This situation is explicitly covered in Policy 7.3 and 7.6.1.
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.
Although it might be sound, my understanding is that it make upgrades
unnecessarily difficult: without the Replaces, one has to completely
deconfigure the old libcoq-mathcomp-analysis (and its
reverse-dependencies) before installing the new one.
Do you have another problem in mind? Or a better fix?
The better fix is to add Breaks *and* Replaces, as instructed by Helmut
and Policy.
Cheers,
--
Stéphane
