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

Re: MBF: Getting rid of unneeded *.la / emptying dependency_libs

On Mon, 4 Apr 2011 16:12:42 -0700
Steve Langasek <vorlon@debian.org> wrote:

> On Mon, Apr 04, 2011 at 07:33:24PM +0100, Neil Williams wrote:
> > > >> Lintian already checks that *.la files don't contain the problematic
> > > >> dependency_libs setting.
> > > This apparently just isn't true.  I could have sworn that we had a check,
> > > but we apparently do not.  We definitely should.  That's probably why
> > > there are so many problems; I suspect a lot of them would go away if there
> > > were a Lintian check.
> > As outlined previously, this does need to be done in a fairly strict
> > sequence which is external to the package. It might be hard for lintian
> > to make this into an error for all packages. 
> > Many packages (all those in the list with depended-on) must not touch
> > their .la files at this stage - including the dependency_libs listing.
> That's not correct.  It is safe for any package to clear out the
> dependency_libs field of any .la file, as far as the OS is concerned.  It is
> a (rather intractable) upstream bug in libtool that it recurses these .la
> files at all at build time when doing dynamic linking on Linux, and the only
> difference between a populated and an empty dependency_libs field for a
> package build is whether or not you get a build failure because a referenced
> .la file is missing.

I'm trying to avoid those build failures, hence not asking for
changes in packages which still have dependencies which will look for
the dependency_libs data at build-time. Those packages only get bugs
filed when those dependencies have been fixed to either clear
dependency_libs or remove the .la file.

e.g. once I fix gpe-expenses to not contain the .la in
libqofexpensesobjects-dev, then qof can be fixed to not include the .la
file in libqof-dev because libpilotobjects-dev has already been fixed
and so it goes on. 

The nice thing about this MBF is that it can all be done within the
Debian revisions of the packages concerned. There are no upstream
requirements here, no changes in debian/patches, so every bug is
potentially fixable with a trivial NMU - as long as the sequence is
followed, we shouldn't see any increase in FTBFS bugs due to this MBF.

> Now, removing this information will impact *static* linking using libtool;
> but that's already largely broken due to the preceding dependency_libs
> removals in the archive, and the number of packages doing static linking in
> Debian can be counted on one hand - none of them using libtool AFAIK.

Exactly. I'm still not sure if it's worth retaining the .a if the .la
is removed. I think for "high-end" libraries like GUIs or any library
which depends on a long list of other libraries, the likelihood of
anyone needing a static linkage of the entire stack is infinitesimal. I
am thinking that libts-dev should retain the .a but I'm open to
comments to the contrary. Currently, I'm thinking of simply removing
the .la file from libts-dev.


Neil Williams

Attachment: pgpAZmx8y3Y06.pgp
Description: PGP signature

Reply to: