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

Bug#1070977: transition: snappy



On 13/05/2024 17:42, László Böszörményi (GCS) wrote:
On Mon, May 13, 2024 at 2:04 PM Emilio Pozuelo Monfort <pochu@debian.org> wrote:
Why is there a libsnappy1v5 transitional package?
  Serves several purposes. As noted, upstream soname is _not_ changed,
so I can't let the old library package be present as it would contain
the same named library file conflicting with the one in the new,
normally named library package name. In short, I must do a file move
between packages. Then the old libsnappy1v5 package has a conflict
with the then old libsnappy1 package name. Thus this conflict needs to
be removed.

Also has upstream been contacted in order to do a proper SONAME bump? Otherwise
libsnappy1 will have to conflict with libsnappy1v5, and that will make both the
transition and upgrades harder, as they have to be done in lockstep. If they
broke the ABI, then a SONAME bump is in order, and that will make it easier for
us too.
  Yup, in such cases a soname bump is needed. Then upstream is Google
and as I remember years back I had a somewhat similar problem with one
of their library package. If I'm correct, I got a similar answer that
in such cases they just recompile the dependent sources and don't
change the soname.
Then the public source tree is hosted on GitHub [1] without the issues
(report) area enabled. The AUTHORS file contains a general email
address (opensource@google.com) [2] meaning I'm not sure if I get any
answer or I will get one soon. But I can try it if you insist.

Looks like this got reported upstream and the symbols got re-added:

https://github.com/google/snappy/issues/183
https://github.com/google/snappy/commit/465b5b60ca410436fa663700c4656ea8f7bf2a95

If that's enough, I assume the package renaming in experimental can be reverted and we just update to snappy 1.2.1, keeping the old library package name.

Cheers,
Emilio


Reply to: