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

[Rocky Bernstein]

On Mon, Mar 12, 2012 at 1:17 PM, Rocky Bernstein <address@hidden> wrote:

>
>
> 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.
>

I looked at this a little and don't think it will help much. The dependency
seems to be that libcdio depends on cdtext. So anything that depends on
libcdio will depend on cdtext.


>
>
>>
>> Regards
>> Leon
>>
>>
>>
>>
>>
>