On Mon, Mar 12, 2012 at 1:17 PM, Rocky Bernstein <[email protected]> wrote:
> > > On Mon, Mar 12, 2012 at 12:48 PM, leon <[email protected]> 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 >> >> >> >> >> >
