Bug#1024637: libmartchus-qtforkawesome1: missing Breaks+Replaces: libmartchus-qtforkawesome0.0.3
Hi Andreas! Andreas Beckmann writes: > On 27/11/2022 21.11, Nicholas D Steeves wrote: [snip] > '/usr/lib/x86_64-linux-gnu/qt5/plugins/iconengines/libmartchus-qtforkawesomeiconengine.so' > in this case. The majority of library packages don't do this and thus > different soversions are co-installable. Thank you for pointing out that the package in question is unusual. To be honest I didn't/don't know if Qt plugins are typically soversioned or sounversioned. As a tangent: "sounversioned" sounds like DLL hell ;) > I'm not sure whether this is avoidable in your case, except by splitting > of the plugin(s) into a separate package. > For this specific src:package, I feel like a bin:plugin-package containing a single small file would probably be considered micropackaging, unless it brought some other benefit. > Perhaps the documentation should document when B+R are needed (see > above) and how this could be avoided. E.g. if libfoo42 needs a datafile > /usr/share/foo/bar.dat that > a) could be moved to a separate package, assuming the datafiles are > compatible between all libfooXX Hm, this seems like it may simultaneously be a Multi-Arch safety question. > b) moved to a package specific path, e.g. /usr/share/libfoo42/bar.dat > if the library is the only user of this file the location/name does not > matter and each soversion would happily use its own file > (I did this in libpapi6.0: /usr/share/papi/6.0/papi_events.csv) > That makes sense :) Should this point be qualified with a link to wiki.d.o/MultiArch/Hints ? As far as I know, that page is required reading for "compatible between all libfooXX" questions...ouf, but so dense... I would much rather wait for Helmut to file a bug with a helpful hint! > Perhaps something like this would help: > "... unless they are strictly neccessary (i.e. there are unavoidable > file conflicts between the packages)" > >> documentation seems misleading and bad, unless there is a special >> exception for library versions involved in a transition. Does such an >> exception exist? > Nope, transitions are not supposed to create more breakage tha normal > uploads. > Gotcha, so there is no magic. The way the wiki article reads made me wonder if there was magic that prevented this breakage...something like a "ben info" -> file transition bug -> release team gives manual hint to dak -> dak somehow attaches further instructions to the deb to do a monkeypatched upgrade when the package is upgraded...of course that's just imagination, but I still wondered. [snip] > > Is the (only) consumer package in testing (if not, it's no transition)? Yes. > Does a binNMU suffice for the consumer package (binNMU bug might > suffice)? Or do you need to upload a new version anyway to make it work > with the new version of the library (you upload both at the same time, > no transition bug unless there is potential interference with other > transitions)? I discovered the need for the new version of this library (qtforkawesome) when I packaged new version of the application and saw it ftbfs. > BTW, you should get an auto-tracker automatically ... it > will tell you whether your mini-transition could interfere with other > transitions (transition bug if that's relevant). > Thank you for this tip! Everything looks clear, and I'm ready to upload. I'll wait a max of one week for your reply about updating the docs before uploading. Yes, they're two different things, but having an RC bug hanging over my head functions as a strong reminder to update the docs haha. Cheers, Nicholas signature.asc Description: PGP signature
Bug#1024637: libmartchus-qtforkawesome1: missing Breaks+Replaces: libmartchus-qtforkawesome0.0.3
On 27/11/2022 21.11, Nicholas D Steeves wrote: I'm bug-testing the documentation on ABI transitions, and it seems we found a bug. The docs say not to add Breaks+Replaces, which seems crazy to me, because, as you noted, it produces a Policy-noncompliant package and a serious bug. Please confirm what you think about the following: * Avoid Breaks and Replaces on the old library packages unless they are strictly necessary * They prevent smooth updates." https://wiki.debian.org/Teams/ReleaseTeam/Transitions It seems to me that there will usually be file-level conflicts, so the There will only be file-level conflicts if a library package ships files/paths that are not versioned with the library, '/usr/lib/x86_64-linux-gnu/qt5/plugins/iconengines/libmartchus-qtforkawesomeiconengine.so' in this case. The majority of library packages don't do this and thus different soversions are co-installable. I'm not sure whether this is avoidable in your case, except by splitting of the plugin(s) into a separate package. Perhaps the documentation should document when B+R are needed (see above) and how this could be avoided. E.g. if libfoo42 needs a datafile /usr/share/foo/bar.dat that a) could be moved to a separate package, assuming the datafiles are compatible between all libfooXX b) moved to a package specific path, e.g. /usr/share/libfoo42/bar.dat if the library is the only user of this file the location/name does not matter and each soversion would happily use its own file (I did this in libpapi6.0: /usr/share/papi/6.0/papi_events.csv) Perhaps something like this would help: "... unless they are strictly neccessary (i.e. there are unavoidable file conflicts between the packages)" documentation seems misleading and bad, unless there is a special exception for library versions involved in a transition. Does such an exception exist? Nope, transitions are not supposed to create more breakage tha normal uploads. Oh, and yes, of course I'm happy to resolve this bug however is best, whether that's with breaks+replaces or filing a transition for a library that is only used by one package, where it's a package that I also maintain. Is the (only) consumer package in testing (if not, it's no transition)? Does a binNMU suffice for the consumer package (binNMU bug might suffice)? Or do you need to upload a new version anyway to make it work with the new version of the library (you upload both at the same time, no transition bug unless there is potential interference with other transitions)? BTW, you should get an auto-tracker automatically ... it will tell you whether your mini-transition could interfere with other transitions (transition bug if that's relevant). Andreas
Bug#1024637: libmartchus-qtforkawesome1: missing Breaks+Replaces: libmartchus-qtforkawesome0.0.3
Hello Andreas, Andreas Beckmann writes: > Package: libmartchus-qtforkawesome1 > Version: 0.1.0-1~exp1 > Severity: serious > User: debian...@lists.debian.org > Usertags: piuparts > > Hi, > > during a test with piuparts I noticed your package fails to upgrade from > 'sid' to 'experimental'. > It installed fine in 'sid', then the upgrade to 'experimental' fails > because it tries to overwrite other packages files without declaring a > Breaks+Replaces relation. > This error may also be triggered by having a predecessor package from > 'sid' installed while installing the package from 'experimental'. > > See policy 7.6 at > https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces > I'm bug-testing the documentation on ABI transitions, and it seems we found a bug. The docs say not to add Breaks+Replaces, which seems crazy to me, because, as you noted, it produces a Policy-noncompliant package and a serious bug. Please confirm what you think about the following: * Avoid Breaks and Replaces on the old library packages unless they are strictly necessary * They prevent smooth updates." https://wiki.debian.org/Teams/ReleaseTeam/Transitions It seems to me that there will usually be file-level conflicts, so the documentation seems misleading and bad, unless there is a special exception for library versions involved in a transition. Does such an exception exist? Oh, and yes, of course I'm happy to resolve this bug however is best, whether that's with breaks+replaces or filing a transition for a library that is only used by one package, where it's a package that I also maintain. Regards, Nicholas signature.asc Description: PGP signature
Bug#1024637: libmartchus-qtforkawesome1: missing Breaks+Replaces: libmartchus-qtforkawesome0.0.3
Package: libmartchus-qtforkawesome1 Version: 0.1.0-1~exp1 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package fails to upgrade from 'sid' to 'experimental'. It installed fine in 'sid', then the upgrade to 'experimental' fails because it tries to overwrite other packages files without declaring a Breaks+Replaces relation. This error may also be triggered by having a predecessor package from 'sid' installed while installing the package from 'experimental'. See policy 7.6 at https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces >From the attached log (scroll to the bottom...): Preparing to unpack .../libmartchus-qtforkawesome1_0.1.0-1~exp1_amd64.deb ... Unpacking libmartchus-qtforkawesome1:amd64 (0.1.0-1~exp1) ... dpkg: error processing archive /var/cache/apt/archives/libmartchus-qtforkawesome1_0.1.0-1~exp1_amd64.deb (--unpack): trying to overwrite '/usr/lib/x86_64-linux-gnu/qt5/plugins/iconengines/libmartchus-qtforkawesomeiconengine.so', which is also in package libmartchus-qtforkawesome0.0.3:amd64 0.0.3-5 Errors were encountered while processing: /var/cache/apt/archives/libmartchus-qtforkawesome1_0.1.0-1~exp1_amd64.deb cheers, Andreas libmartchus-qtforkawesome0.0.3=0.0.3-5_libmartchus-qtforkawesome1=0.1.0-1~exp1.log.gz Description: application/gzip
