[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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



On Sun, Nov 27, 2005 at 06:05:52PM +0100, Henning Makholm wrote:
> > > 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.

I agree that we need better granularity than per-source.  I actually think
that having it per object file is ideal in the long run, though in the short
term doing it per binary package means less confusing noise.

Cheers,
-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon@debian.org                                   http://www.debian.org/

Attachment: signature.asc
Description: Digital signature


Reply to: