[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#951209: transition: libgusb



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


Reply to: