[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Libcdio-devel] CD-Text API changes
From: |
Nicolas Boullis |
Subject: |
Re: [Libcdio-devel] CD-Text API changes |
Date: |
Mon, 12 Mar 2012 12:12:52 +0100 |
User-agent: |
Mutt/1.5.20 (2009-06-14) |
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