On Wed, 12 Feb 2020 at 15:24:42 +0100, Laurent Bigonville wrote: > libgusb is carrying in debian a patch[0] to revert/fix an after the fact > change that was done upstream in the versioning of the symbols. > > I don't think we should/can carry this patch forever and due to the fact > that the number of reverse-dependencies is quite limited, I was planning > to simply drop it, but that would require to binNMU them to be > certain they are using the correct version of the symbol.
Is the maintainer of libgusb aware of this transition plan? Note that upstream broke the ABI *again* in 0.3.4. They tried to freeze the ABI by introducing new checks, but the new checks accidentally dropped a symbol (fix proposed in <https://github.com/hughsie/libgusb/pull/31>). If we want to do anything with the ABI, I think it would be a good idea to base what we do on 0.3.4. On Tue, 03 Mar 2020 at 20:19:12 +0100, Julien Cristau wrote: > IMO we should keep compatibility with the old version until the next > upstream SONAME bump. That might mean keeping this patch, or something > different, if we can add properly versioned aliases for the affected > symbols? I've proposed https://github.com/hughsie/libgusb/pull/33 upstream and https://salsa.debian.org/debian/libgusb/-/merge_requests/2 in Debian. I would recommend waiting to see what upstream say about #33 before applying anything in Debian. smcv
