Re: RFS: xz-utils (updated package)
* Jonathan Nieder <jrnieder@gmail.com>, 2011-10-17, 23:49:
- http://alioth.debian.org/~jrnieder-guest/temp/xz-utils_5.1.1alpha+20110809-3.dsc
In debian/patches/abi-liblzma2-compat you wrote:
| Applications linked directly to liblzma2 and indirectly to liblzma5 use
| the implementation from liblzma5
I don't claim to be an expert on symbol versioning, but I did some
experiments, and it doesn't seem to be the case. If a program is linked
to two versions of a library, one of which doesn't use versioned
symbols, then the symbols from the directly-linked one shadows the
other.
| $ LD_PRELOAD=/usr/lib/x86_64-linux-gnu/liblzma.so.5 xz README
| xz: README: Unsupported options
Well, that's not really a simulation of an application linked directly
to liblzma2 and indirectly to liblzma5...
| Unfortunately one cannot even get lucky and find the symbol from
| liblzma2 used from time to time: versioned symbols take precedence over
| unversioned ones when resolving unversioned references.
As far as I can tell, this is not the case.
All in all, while the patch probably have merits (I didn't have time to
look closely), the rationale seems flawed to me.
In debian/symbols there is:
| (symver)XZ_5.0 5.1.1alpha+20110809
To be pedantically correct, that should be:
| (symver)XZ_5.0 5.1.1alpha+20110809-3~
On the other hand, since you've just bumped SONAME, it doesn't matter at
all. You could have used even 0 here.
I am not entirely happy about your "liblzma_private_symbols" hack. It
might work well for now, but I wouldn't be surprised if it'll make your
package FTBFS with a future version of dpkg-dev, if it becomes stricter
at validating input.
--
Jakub Wilk
Reply to: