Re: [Libcdio-devel] CD-Text API changes

[Rocky Bernstein]

On Mon, Mar 12, 2012 at 12:48 PM, leon <address@hidden> wrote:

> On 2012-03-12 12:12, Nicolas Boullis wrote:
>
>  First I thought it to be easier this way. But the more I think about
>>> it, keeping localization in mind, the less I like it. Any other
>>> opinions?
>>>
>>
>> Sorry, I don't understand what you mean. What way did you first think
>> to be easier?
>>
>>
> Sorry. When I introduced that function I thought it to be more convenient
> to call cdtext_select_language with "English" or "French" as an argument
> rather than  calling it with CDTEXT_LANG_ENGLISH.
> But since you mentioned it and I looked over example/cdtext.c I am not so
> sure anymore. At this point we can still change it... What do you think?


Why not allow both?


>
>
>  I am not a package maintainer and I do not know how they think. How
>>> big of a problem would it be to have it changed?
>>> But there are only two projects I know about that use libcdios
>>> CD-Text and I will try to help them make the necessary changes.
>>>
>>
>> As a package maintainer, I can explain how things work, from my point of
>> view.
>>
>> When a library's ABI change incompatibly, we must ensure that programs
>> dinamically linked with the old one do not try to run with the new one,
>> or one might experience ugly bugs. That's the point of the SONAME. The
>> SONAME is the name a binary will look for when it tries to load the
>> library. Hence, libcdio has different SONAMEs for different versions,
>> like libcdio.so.13 for libcdio 0.93 or libcdio.so.10 for libcdio 0.91.
>> Basically, at the binary level, those are different libraries.
>>
>> Now, when a library's SONAME change, we must either rebuild all the
>> programs that use this library, or keep the old version along. I am not
>> willing to maintain several versions of libcdio within Debian, I don't
>> think it's worth the effort. But then we have to coordinate the
>> transition of libcdio and all programs that use it from Debian unstable
>> to Debian testing. And if there is any of those programs that can't move
>> from unstable to testing (because it has a bad bug, or because of
>> another transition in progress) then it may become a big problem for the
>> release team.
>>
>
> Thanks for the explanation.
>
>
>  >Now, a side note: shouldn't CDText functions be kept in a separate
>>> >library, distributed with libcdio, just like libiso9660, libudf and
>>> >libcdio-cdda? This would allow to break the ABI of this new library
>>> >without breaking libcdio's ABI. Any opinion on this?
>>>
>>> Hm how would this help with the current problem? If the new libcdio
>>> version will not have the cd text part, it would essentially mean
>>> another ABI change...
>>>
>>
>> You're absolutely right, it wouldn't help at all with the current
>> problem.
>> But it might help in the future if the ABI had to change again (a
>> libcdio-cdtext transition might impact fewer programs than a libcdio
>> transition, and hence would be easier to handle).
>> The other reason is that I think it would be more consistent. As I
>> understand it, libcdio is for low-level stuff, while higher-level stuff
>> is handled in "sister" libraries, like libudf or libiso9660.
>> The last reason is that I think it would be better if each library used
>> a clearly defined namespace, such as cdio_* for libcdio. That would
>> limit the chance for conflicts, such as the cdtext_init symbol that
>> exists both in libcdio and libcue. A bug was filed against the Debian
>> libmpd package (and libcdio and libcue) because libmpd used to link with
>> both libraries:
>>  
>> http://bugs.debian.org/cgi-**bin/bugreport.cgi?bug=597731<http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=597731>
>>
>
> Sounds reasonable. But we should keep in mind that cdtext only has a few
> hundred lines of code and at this point libcdios CD-Text implementation is
> somewhat complete so I don't see more changes coming. At least none that
> would break the ABI.
>

Famous last words. I don't know right now what it will take, but I'll look
into splitting it into a separate library.


>
> Regards
> Leon
>
>
>
>
>