Re: Handling macro change in an exported library header

2008-06-27 Thread Adeodato Simó
* Russ Allbery [Thu, 26 Jun 2008 17:08:56 -0700]: > Nikita Youshchenko <[EMAIL PROTECTED]> writes: > >> If the expr had a bug and old binaries didn't work with the old library > >> then I would say that requires and shlibs bump, possibly a versioned > >> conflicts against all rdepends and binNMUs

Re: Handling macro change in an exported library header

2008-06-26 Thread Russ Allbery
Steve Langasek <[EMAIL PROTECTED]> writes: > My understanding from reading this thread is that the signature of the > function did *not* change, but that in previous versions of the library > the macro definition in the header was simply broken, with the result > that anything built using that def

Re: Handling macro change in an exported library header

2008-06-26 Thread Steve Langasek
On Thu, Jun 26, 2008 at 05:10:40PM -0700, Russ Allbery wrote: > "Joe Smith" <[EMAIL PROTECTED]> writes: > > If the change is a define in a header, where said define is *not* used > > in the library itself, then the libraries binary will not change. Thus > > physically it would have the same API an

Re: Handling macro change in an exported library header

2008-06-26 Thread Russ Allbery
"Joe Smith" <[EMAIL PROTECTED]> writes: > If the change is a define in a header, where said define is *not* used > in the library itself, then the libraries binary will not change. Thus > physically it would have the same API and ABI. If the new behavior of the header file is required for the new

Re: Handling macro change in an exported library header

2008-06-26 Thread Russ Allbery
Nikita Youshchenko <[EMAIL PROTECTED]> writes: >> If the expr had a bug and old binaries didn't work with the old library >> then I would say that requires and shlibs bump, possibly a versioned >> conflicts against all rdepends and binNMUs. > As far as I understand, as soon as source uses the aff

Re: Handling macro change in an exported library header

2008-06-26 Thread Joe Smith
"Bernhard R. Link" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] * Nikita Youshchenko <[EMAIL PROTECTED]> [080626 11:51]: 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

Re: Handling macro change in an exported library header

2008-06-26 Thread Bernhard R. Link
* Nikita Youshchenko <[EMAIL PROTECTED]> [080626 11:51]: > 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 e

Re: Handling macro change in an exported library header

2008-06-26 Thread Nikita Youshchenko
> If the expr had a bug and old binaries didn't work with the old > library then I would say that requires and shlibs bump, possibly a > versioned conflicts against all rdepends and binNMUs. As far as I understand, as soon as source uses the affected macro, binary is broken if compiled against un

Re: Handling macro change in an exported library header

2008-06-26 Thread Adeodato Simó
* Nikita Youshchenko [Thu, 26 Jun 2008 13:22:19 +0400]: > 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 thi

Re: Handling macro change in an exported library header

2008-06-26 Thread Adeodato Simó
* Neil Williams [Thu, 26 Jun 2008 12:33:33 +0100]: > SONAME bump would seem appropriate W. T. F. (Hint: no, it is not appropriate.) [snipped completely irrelevant stuff to the case at hand] -- Adeodato Simó dato at net.com.org.es Debian Developer

Re: Handling macro change in an exported library header

2008-06-26 Thread Goswin von Brederlow
Nikita Youshchenko <[EMAIL PROTECTED]> writes: > 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

Re: Handling macro change in an exported library header

2008-06-26 Thread Neil Williams
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 ro

Re: Handling macro change in an exported library header

2008-06-26 Thread Neil Williams
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

Handling macro change in an exported library header

2008-06-26 Thread Nikita Youshchenko
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 do