> Adeodato Simó wrote:
>> So, to get this moving, who does the archive inspection?
I wrote:
> As it happens, I already had a script prepared that did something very
> similar (for the purpose of looking for mis-compiled gfortran code on
> mips*). I've modified it to look for r-depends of libexpat1 containing
> ELF files having a NEEDED libexpat.so.0 and it's running now. (At the
> moment it's processing packages in Etch; on i386, amd64 and powerpc
> architectures; main, contrib and non-free components). Should be done
> in a few hours, and I'll post the results and the script here. Let me
> know if you'd like me to search additional architectures or distributions.
I've finished with the script run (the script is attached for
completeness although it is pretty straightforward), and the conclusion
is this: of the packages with a direct dependency on libexpat1, NONE of
them (in Etch on i386, amd64, or powerpc; looking at main, contrib and
non-free) contain an ELF file with NEEDED libexpat.so.0.
What about the wink package, you ask? It turns out that wink doesn't
declare a package dependency on libexpat1. It avoids an RC bug because
the dependency still exists indirectly through the chain
wink -> libgtk2.0-0 -> libfontconfig1 -> libexpat1.
How is it that wink doesn't pick up libexpat1 via ${shlibs:Depends}?
The only Build-Dep of wink source package is debhelper, since the
"source" package actually ships a tarball of pre-compiled binaries (wink
being in non-free). So libexpat1 wasn't installed on the build system
at the time dh_shlibdeps was run from wink's debian/rules. I guess this
may be a general weakness of non-free "source" packages that ship
pre-compiled binaries. (There does not seem to be a Lintian check for
this, presumably because such a check would require Lintian to know the
mapping from the library sonames in NEEDED to package names.)
This implies that it is also necessary to examine non-free packages with
an *indirect* dependency on libexpat1. I did so on Etch/i386 by taking
the output of "apt-cache --recurse rdepends libexpat1" and extracting
the subset of packages which are in non-free with Arch: i386 (rather
than Arch: all), and also missing a direct libexpat1 dependency (since
the packages with direct libexpat1 dependency were already checked).
There are 101 such binary packages on Etch/i386. The only one which has
an ELF file with NEEDED libexpat.so.0 is wink.
Of course it's conceivable that there is a pre-compiled binary packaged
on some non-i386 architecture that needs libexpat.so.0. But the vast
majority of pre-compiled binaries for Linux are made available only for
i386, so I think it's quite unlikely. Thus I'd suggest just contacting
wink upstream about a fix, and not bothering about a libexpat0
compatibility package.
best regards,
--
Kevin B. McCarty <kmccarty@gmail.com>
WWW: http://www.starplot.org/
WWW: http://people.debian.org/~kmccarty/
GPG: public key ID 4F83C751
Attachment:
libexpat0-detector.sh
Description: application/shellscript
Attachment:
signature.asc
Description: OpenPGP digital signature