On Thu, 2008-06-26 at 12:33 +0100, Neil Williams wrote: > > Any comments on how to handle this change in packaging properly? > > Maybe upstream could implement a "deprecated" support scheme that allows > the old routine to be available, puts the new routine under a new name > and moves the old routine into deprecated.c which can be disabled en > masse with an option to ./configure. Packages then use the new function > in their bug fix. deprecated.c then grows in size as more changes are > implemented but the SONAME remains the same (you simply increment the > version string upstream: 13:1:0 etc). (Should also note that where this says "function" or "routine", any snippet of code from the public API can be handled in the same way, including macros - see deprecated.c and deprecated.h in the current libqof1 source in Debian.) -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
signature.asc
Description: This is a digitally signed message part