Hi Steve,
On Thu, May 16, 2013 at 5:41 AM, Steve Langasek <vor...@debian.org> wrote:
> Hi Ondřej,
>
> On Tue, May 14, 2013 at 03:12:02PM +0200, Ondřej Surý wrote:
>> JSON-C upstream has renamed the library from libjson.so to
>> libjson-c.so, headers are now in /usr/include/json-c and pkg-config is
>> called json-c.
>
>> There's a compatibility layer (symlinks and libjson.so.0), but since
>> the library has so few r-deps, I feel that we might not need it to
>> make things more simple in the future. The upstream is planning to
>> drop the compatibility layer in next release anyway, so we would have
>> to do the transition in some other point in time.
>
> Not necessarily. If the ABI has not changed, there is no reason that we
> should not keep the compatibility layer in place in Debian *indefinitely*.
>
> For another example of this, see libcurl3-gnutls.
There are some new symbols in libjson-c library and _no_ symbols in libjson
>> There are no library symbols removed (just added), so the transition
>> should be relatively painless (you will just have to do s/json/json-c/
>> in your packages).
>
>
>> Ben file:
>>
>> title = "json-c";
>> is_affected = .depends ~ "libjson0" | .depends ~ "libjson-c2";
>> is_good = .depends ~ "libjson-c2";
>> is_bad = .depends ~ "libjson0";
>
> It looks like you're coupling a transition of the runtime library package
> name with a transition of the build-time API. The first is not required at
> all - the runtime library package name should change IFF there is a
> backwards-incompatible ABI change, which there isn't in this case *unless*
> we drop the compat symlink (which we therefore should just never do). The
> second could arguably be made a soft transition, with
> backwards-compatibility support added so that this doesn't gum up testing
> transitions unnecessarily; but as you point out, the set of affected
> packages is small, and as long as it's not coupled with an unnecessary
> change to the runtime lib package name this is probably acceptable - but
> this is a question the release team should decide on.
The upstream compatibility layer consists of:
symlink in /usr/include/json/ -> json-c
json.pc in /usr/lib/pkgconfig
and libjson.so.0 which has no symbols, and just links to
libjson-c.so.2. My knowledge of dynamic linker isn't that great, but I
very much doubt this is a "drop-in" replacement for original
libjson.so.0 _with_ symbols, so at least bin-NMU would be needed. But
I might be mistaken here.
Also since libjson0 has dropped original symbols, it needs SONAME
bump, so we would have libjson1.
If there's a need to keep the compatibility layer I am inclined to:
- drop libjson0
- keep libjson0-dev with the symlink and modified json.pc with
-ljson-c. This might still break applications which hardcode the
library name (e.g. they don't use pkg-config), so I am still quite
unsure it's worth from long term.
So overall I would still suggest short term pain, which can be solved
by coordinated uploads and NMUs on those few packages which will
break.
But I would leave that decision in the hands of our release managers.
Ondrej
P.S.: I can prepare both variants (with and without libjson0{-dev}, so
you can check them. I already have that buried somewhere in the git,
since my first update of the package was with libjson0{-dev}
compatibility layer kept.
--
Ondřej Surý <ond...@sury.org>
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
