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