Hi Andreas! Andreas Beckmann <a...@debian.org> 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
