Re: Bug#669373: RFS: flactag/2.0.1-1 ITP #507876
On 13/05/12 14:09, Andy Hawkins wrote:
> Hi,
>
> In article <[🔎] 4FAE92F8.4070305@pocock.com.au>,
> Daniel Pocock<daniel@pocock.com.au> wrote:
>
>> "Both Debian packages are called libmusicbrainz4, yet
>> OLD: code v2.1.x, SONAME = libmusicbrainz.so.4, ABI = 4
>> NEW: code v4.0.x, SONAME = libmusicbrainz4.so.3, ABI = 3"
>>
> But limbm3 (the immediate previous version)
>
> is
>
> v3.0.2, SONAME = libmusicbrainz3.so.6. I assume the ABI is 6 from this.
>
>
Ok, so there isn't a great pattern to follow
Are there similar packages we can compare to?
>> The very first step, before even deciding upon the package name, is to
>> decide about the SONAME
>>
>> Should the number 4 be there? Or should 4.0.x have been released using
>> SONAME libmusicbrainz.so.5? (same as v2.1.x, but bumping up the ABI number)
>>
> I think having the number 4 in there is a good idea, as it means you can
> easily have libmb3 and libmb4 installed side-by-side (to allow applications
> using the older one to co-exist with the newer one).
>
>
What does that mean in practice? As a way of being able to use either
the new or the old XML web API? Or both libs working against the same
XML web API, but some client applications have simply not been updated yet?
With some packages, like libdb, this seems to be a reality: people have
different versions of db files on disk (particularly if shared
filesystems are involved), and they need to be able to work with them.
Not every library (or package) is compelled to give such flexibility though
>> My recommendation is to go back to the old SONAME format. In any case,
>> that decision must be made before the package can be named.
>>
>> If you continue using the SONAME libmusicbrainz4.so.*, then I think you
>> might legitimately end up with dev packages having names like
>>
>> libmusicbrainz4-3-dev
>>
>> but I just think that is confusing because of the way `libmusicbrainz4'
>> has been used in the past
>>
> My current preferred strategy is:
>
> 1. When the next server version is released (this week) release libmb4.0.2
> using the existing scheme
>
>
I think a new server version may justify a libmb 4.1.0, just to
emphasize something is changing
> 2. Immediately release libmb5.0.0, with SONAME libmusicbrainz5.so.5
>
>
I think that is fine, but it is also 100% valid if you use the SONAME
libmusicbrainz.so.5
I'd be interested to get feedback from other people who have more
extensive experience of library packaging than myself though, I'm simply
working from what I've read in the GNU libtool guide and the Debian
library packaging guide.
> This will retain ABI compatibility with anyone currently using libmb4, and
> also get around any naming issue with the old limbm2 package.
>
>
I agree that is a priority - we can't wait for Debian to flush out the
old lib (although we should aggressively encourage them to do so as it
wouldn't be nice to see it in wheezy by mistake, given that the XML API
is no longer supported by the musicbrainz.org web service)
Reply to: