On Wed, 10 Jan 2007 09:36:28 -0800 "Kevin B. McCarty" <kmccarty@Princeton.EDU> wrote: > Thanks everyone who answered so far! Unfortunately some of the answers > (Steve Langasek's vs. Neil Williams') seem directly opposed :-) In such cases, I defer to vorlon. :-) > > A better solution for libfoo, IMHO, is for libbar to use barB() and barC > > () then libfoo can retain B() and C() until such time as all > > applications have migrated to barB and barC. > > Understood, but this isn't really an option for me. The issue is that I > maintain a library [*] whose source includes embedded code from old > versions of libXbae and libXaw, and I've just been notified of this > fact. I would really rather remove that code and link it dynamically > against external versions of those libraries (for obvious security and > maintainability reasons). Not being upstream of libXbae or libXaw, I > really can't change the name of the functions in question in those > libraries. Understood - I had a situation like that with my own library but at that time I had a perfect reason to bump the SONAME so I merged this change into the other changes to make libqof1. The method I described is how I make subsequent changes within libqof1 in preparation for libqof2 when the deprecated stuff is to be completely removed. QOF includes SQL handling code originally lifted from libgda, so on Debian, libqof1 uses libgda2-3 to provide this code. However, since libqof1 this has been done via a *compile time* switch so the effect is now quite different. (I'm upstream for QOF too.) > Upstream of my library (Cernlib maintainers) only ships static > libraries, and the shared library support is hacked in by me. So I have > complete control over the soversion, but of course I'd rather not bump > it if I can get away without doing so. ... especially so close to Etch ... -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
pgpOt6OBToe9z.pgp
Description: PGP signature