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

[leon]

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?

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

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.

Regards
Leon