Re: Bug#340934: lintian check for unneeded/transitive shlibs dependencies

[Henning Makholm <henning@makholm.net>]

Scripsit Peter Samuelson
> [Henning Makholm]

> > I have written a Lintian check which attempts to flag instances of
> > this problem. It looks for ELF objects that flag shared libraries in
> > the default search path as NEEDED without actually importing symbols
> > that the library exports.

> This produces a lot of noise in a case where a package has multiple
> binaries or libraries (sometimes in multiple packages), and a Makefile
> that links everything to a common set of libs which not everything
> needs.  Your check flags this correctly, but it can be a real pain to
> fix, and doesn't usually cause practical problems - particularly the
> problem Steve writes about.  Remember, the granularity of testing
> migrations and library transitions is not the file or even the binary
> package, but the source package.

This appears to be a fair point. I think I'll revise my proposal so it
works per .deb rather than per object file.

I'd like to see some broader debate, however. I am not conviced that
the entire _source_ package is the right level to check this at. Steve
mentioned two problems - one is painfullness of library transitions,
the other is segfaults in case of partial upgrades. While the first
problem indeed works on the source package level, the second is often
a matter between binary packages with the same source.

For a concrete example, consider #260938. The autotrace source package
builds binary packages libautotrace3 and autotrace; the latter
contains a client for the library in the former. A user upgraded the
client package without upgrading the library. This _ought_ to have
worked because the ABI of the library itself was indeed unchanged.
But the upgraded client spuriously pulled in different versions of
some library that was, in fact, used only by libautotrace, and a
segfault resulted.

Had a lintian check for spurious linking existed at the time, I would
have noticed that the client binary requested too many shared libs
and have an opportunity to fix it because it hit a user with a sefault.

-- 
Henning Makholm                         "This imposes the restriction on any
                                  procedure statement that the kind and type
                             of each actual parameter be compatible with the
                       kind and type of the corresponding formal parameter."