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

[Nicolas Boullis]

On Mon, Mar 12, 2012 at 08:48:03AM +0100, leon wrote:
> On 2012-03-12 01:20, Nicolas Boullis wrote:
> >I am a bit curious: why does cdtext_select_language take a "const
> >char *"
> >parameter for the language, while cdtext_get_language and
> >cdtext_languages_available return cdtext_lang_t value(s)? Wouldn't
> >it be
> >more consistent if cdtext_select_language too, a cdtext_lang_t
> >parameter?
> 
> 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?


> It most likely would require this, yes. Practically it would be the
> same as providing two different versions of the functions, as we
> discussed some days ago. We abandoned that idea because of the
> massive complications it would have caused.

And I agree with this.


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


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


Cheers,

-- 
Nicolas