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?

Nikita


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

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/

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/

Nikita Youshchenko <yoush@debian.org> 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 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?
>
> Nikita

Are you saying that old binaries will no longer work because param2
will be wrong? If so then the ABI changed.
You might want to use

extern int foo(char *param1, int param2);
extern int foo_new(char *param1, int param2_new);
#define bar(param) foo(param, expr(param))

or versioned symbols to keep the old and new binaries working. In that
case the ABI doesn't break so only shlibs/symbols file need to be
bumped.


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.

MfG
Goswin


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

> 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 unfixed version of the library, regardless of what
library (fixed or unfixed) it links against at runtime.

If source is compiled against fxed library, it will work correctly (at least
at this point) regardless of what version of library it is linked at runtime.

It looks that I may just upload the fix, without changing soname or shlibs,
and then notify rdepends? Maybe also write a note into README.Debian in -dev
package?


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

* 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 adeodato at debian.org

I promise you. Once I enter into an exclusive relationship, I sleep with
very few people.
-- Denny Crane


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

* 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 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?

My understanding from reading the bug and seeing the diff, is that you
should just apply the patch.

Recompiling code that uses the bar() macro would be indeed nice, so
maybe you could unpack all the packages that build-depend on your
library, and grep them for bar()? If you send a list of matches to
debian-release@lists.debian.org, we can rebuild them with binNMUs then.

Cheers,

--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org

La música es de los que la quieren escuchar y de nadie más.
-- Andrés Calamaro


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

* Nikita Youshchenko <yoush@debian.org> [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 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.

I think the relavant questions are: what is semantically changing:

1) Library keeps the behaviour, headers change, code using the headers
must change because now the macro means something else
-> ABI (and thus soname) kept, API changes

(I do not know if there is a reasonable way packaging-wise to deal
with this, perhaps renaming the -dev package might be sensible,
depending on the impact).

2) Library keeps the behaviour, headers change, but intended behaviour
does not change (i.e. fixing some bug):
-> ABI and API stay, programs using the library may need an binNMU
to actually use the bugfix.
(Dato's mail indicates that is the case here.)

3) Library changes behaviour, headers adopted to get the original
behaviour when using the define.
For example function now wants an argument now one bigger or
smaller to mean the same.
-> ABI changes, and API too (unless using the symbol directly
is made impossible somehow).
-> soname bump needed (IMHO)

Where "changes behaviour" might be a bit tricky. Here it means "changes
meaning of the arguments". Where "before this argument = 0 meant
segfault now it means what was always in the documention" is not a
change of behaviour on that sense, but "before it was the length without
terminator, not it is the length with terminator" is a change.

Hochachtungsvoll,
Bernhard R. Link
--
"Never contain programs so few bugs, as when no debugging tools are available!"
Niklaus Wirth


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

"Bernhard R. Link" <brlink@debian.org> wrote in message
news:20080626152905.GA11440@pcpool00.mathematik.un i-freiburg.de...

* Nikita Youshchenko <yoush@debian.org> [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 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.


I think the relavant questions are: what is semantically changing:


My thoughts:

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. However, the convience API
would change. So the end applications would need to be recompiled to take
advantage of this, but since either version of the binary of the library
would work with these recompiled apps. So the library should not be changed,
but the programs recompiled, and a warning added to readme.Debian warning
that locally compiled programs must be recompiled with the new headers.



However if the library itself used the macro, then it has a true API change,
and must be SONAME bumped.




--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Nikita Youshchenko <yoush@debian.org> 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 affected macro,
> binary is broken if compiled against unfixed version of the library,
> regardless of what library (fixed or unfixed) it links against at
> runtime.

In that case, the ABI did actually change, and the SONAME needs to be
increased.

The SONAME doesn't have to be increased only if existing binaries compiled
with the old library will continue to work with the new library.

--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org