Re: Upcoming libgd2-{xpm,noxpm}-dev -> libgd2-dev transition
Hi,
On 2013-05-15 09:58, Ondřej Surý wrote:
> On Wed, May 15, 2013 at 7:55 AM, Guillem Jover <guillem@debian.org> wrote:
>> Might I suggest libgd-dev instead? If a later API revision makes lots
> The upstream position is that MAJOR release will break API. (But who
> knows if that ever happens). So I think the libgd2-dev actually
> reflects the reality pretty well.
Since you are doing a transition anyway (currently optional to change
the source packages since there are compatiblity packages), you can move
to a proper name now.
And worry about possible transitions for gd-3.x (libgd4, libgd4-dev)
later ...
> I might however add "Provides: libgd-dev" to libgd2-dev package, but
> nothing depends on libgd-dev now, so I don't really see a need for it.
>>> The ABI has remained same as well, but I have decided to bump the
>>> SONAME to 3, because I have implemented the GCC visibility magick,
>>> so only symbols, which were ment to be exposed, are exposed now.
>>
>> If the SOVERSION is now 3, then the shared library package would need
>> to be called libgd3 (and libgd3-dev or as mentioned above ideally
>> libgd-dev), or did I misunderstood something in the above?
>
> The '2' in libgd2-dev is from 2.x.x, and not from the SONAME to
> reflect the API version (1 vs 2).
Which is, at least, confusing, as it is different elsewhere. And
violates Policy Chapter 8. libgd2-3 would be acceptable, an acceptable
-dev package would probably be libgd2-3 dev.
[Another interesting case where SOVERSION does not match VERSION is the
(correctly named) package pair libtiff4 and libtiff5, built from
tiff3 (3.x) and tiff (4.x)]
> I was thinking about renaming the shared package to libgd3, but it
But this would be the right thing to do.
> would be quite confusing to have libgd2-dev to go with libgd3.
But paring libgd-dev with libgd3 sounds fine.
Andreas
Reply to: