On Thu, 2008-06-26 at 13:22 +0400, Nikita Youshchenko wrote: > Hello. > > To fix #486693, I need to apply a patch that changes #define'd macro in an > exported library header. > > The pattern is: > > extern int foo(char *param1, int param2); > #define bar(param) foo(param, expr(param)) > > and changed thing is expr(param) > > Looks like binary interface of the shared library does not change, however > strictly saying any user of the library that uses bar() macro needs to > recompile his code. > > Any comments on how to handle this change in packaging properly? SONAME bump would seem appropriate but the current SONAME is already 13 and it seems to be changing every few releases. 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). Along with that, if you convince upstream to use versioned symbols, the dependency info will be right too - each reverse depends will get the version that implements the fixes that it uses. Always ensure that the old, buggy, function remains in place in deprecated.c *completely unchanged* for ABI/API compatibility, the bug can then be fixed in the applications using the library by migrating to the replacement function. Then dependencies could migrate through the changes until finally able to use --disable-deprecated-etpan. Then, in a coordinated manner, the library can drop all deprecated code so folding all changes into one SONAME bump. etc. There's nothing you can do to change old SONAME bumps now but this would prevent you having libetpan476 by Lenny+2. :-) (This is how I do it for libqof1 - libqof2 is due after Lenny and drops more than 50 interfaces by dropping all content from deprecated.c but all reverse dependencies can already build against libqof2 whilst testing simply by passing --disable-deprecated-qof to ./configure. This means that I can ensure that all reverse dependencies can cope with libqof2 transparently before it is released *AND* I can fold all changes into one SONAME bump. Without deprecated.c, I'd already be on libqof68 or more. As it is, libqof1 in Debian (0.7.5) can pretend to be libqof2 with a mere ./configure switch, at least as far as testing is concerned.) -- 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