[Pkg-libburnia-devel] Bug#1014400: libisofs: Add symbol file

[Thomas Schmitt]

Hi,

i wrote:
> > So if the Debian packaging software decides on its own that
> > libisofs-1.5.2 is enough at package build time, then compilation
> > [of libisoburn] will fail.

Alexandre Ghiti wrote:
> In an ideal world, the symbols should be backward compatible and then the
> 'symbols' mechanism should be enough: I'm curious, why would it be different
> here?

The ABI's of libburn and libisofs are indeed backwards compatible.
I.e. it should be no problem to link an old libisoburn, Xfburn or
Brasero with new versions of libisofs.
What i prevent as upstream is that new libisoburn links with old versions
of libisofs. Normally there is the hard reason that new symbols of libisofs
being used. But there is also the reason to keep old bugs from infesting
newer versions of xorriso.


> > Is that file format specific to Debian and its derivatives or
> > does it play a role in more generic build facilities ?

> I can't really say, let's wait for the package maintainer on this.

Well, half of this maintainer role is fulfilled by me. I care for upstream
related aspects and try to keep some of the Debian tools happy with the
package parameters on salsa.
Dominique Dumont coaches me in respect to Debian packaging skills. He
also has the last say about what i do on salsa and eventually risks his
reputation by uploading our combined work.

We have the lintian warning no-symbols-control-file since a while.
If it is desirable to silence it by a more or less dummy symbol file,
then i would develop a script which generates it from the existing .ver
file.
Dominque would then hopefully tell me how to integrate that script into
debian/rules (or wherever it belongs).

As stated above, there would be the risk of compilation failure with
libisoburn, if we would give dpkg the opportunity to decide against the
inner version demands of libisoburn.
So i see only the option to have that dummy .symbols file which just says
what is available now in the current version, but gives no version
history.

If .symbols were a general concept outside of Debian's packaging world,
then i would consider to maintain it upstream and to keep libisoburn's
inner expectations in sync with the .symbols file. (Normally it would
still want the newest libisofs because normally new symbols there are
introduced to fulfill needs of libisoburn and xorriso.)

As it appears now from googling, i think Dominique can decide either that
we leave out .symbols, or that we create the dummy symbols file.
In the latter case i'd need coaching about generating the dummy under
control of debian/rules.


Have a nice day :)

Thomas