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
