FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 04-04-2011, 06:33 PM
Neil Williams
 
Default MBF: Getting rid of unneeded *.la / emptying dependency_libs

On Mon, 04 Apr 2011 10:49:04 -0700
Russ Allbery <rra@debian.org> wrote:

> Neil Williams <codehelp@debian.org> writes:
> > The line in the original data is:
>
> > shibboleth-sp2: dependency_libs links-not-existing-la
>
> > The original criteria were:
>
> > 1. "no flag" to remove the la-file on next occasion
>
> > 2. only "dependency_libs" to remove their la-file RSN, because they
> > block removal of the la-files on another package (this flag can be
> > wrongly hit if a package depends only on itself - but well,
> > dropping the la-file is recommended as well here as with 1.)
>
> > 3. only "depended-on" to do nothing at this time
>
> > 4. with both "dependency_libs depended-on" to use
> > sed -i "s,^dependency_libs=.*,dependency_libs=',"
> > on all their la-files (I took care that self-dependencies don't
> > appear in this category, but rather in 1 or 2).
>
> > So where is the error? In the original data?
>
> No, indeed, dependency_libs should be stripped from those files. It
> doesn't need to be, really, since it's obviously never used by anything
> (referencing non-existent files as it does), but for cleanliness it should
> go anyway.
>
> I believe the *.la files need to stay since I think upstream is loading
> modules that way, but I will double-check. But they're harmless for
> Debian as a whole.

OK, so this is one of those situations where the .la file, with or
without dependency_libs IS useful - Sune pointed out another. It does
sound, though, that these are exceptions rather than routine.

> >> 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.

I think we need to get this Release Goal completed and *then* set up a
lintian warning for *any* .la file which must be explicitly overruled
for those exceptions which actually use the .la file. There could also
be an error if any package then includes an .la file with
dependency_libs - only once the entire process is complete first time
around. That could be a while...

With the caveats already covered in this thread (excepting kdelibs), are
there objections to a MBF for this outdated Release Goal? We've already
missed this Release Goal once, probably because no bugs were filed
first time around.

I'd phrase it something like:

"In most cases, the .la file can simply be removed as the process
behind this MBF has already identified that there are no further
dependencies using the .la file. In the unusual case that your package
uses libltdl directly, it is still necessary to empty the
dependency_libs part of all .la files remaining in the package. Once
this package is fixed, the process will repeat and other packages may
need to be fixed in turn. If you believe that your package needs both
the .la file and the dependency_libs settings, please raise this on
debian-devel for clarification."

Right. Time for me to make some uploads to fix my own packages for this
run and then look for the next set.

--


Neil Williams
=============
http://www.linux.codehelp.co.uk/
 
Old 04-04-2011, 11:12 PM
Steve Langasek
 
Default MBF: Getting rid of unneeded *.la / emptying dependency_libs

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.

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.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org
 
Old 04-05-2011, 07:41 AM
Neil Williams
 
Default 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
=============
http://www.linux.codehelp.co.uk/
 
Old 04-07-2011, 06:50 AM
Steve Langasek
 
Default MBF: Getting rid of unneeded *.la / emptying dependency_libs

On Tue, Apr 05, 2011 at 08:41:37AM +0100, Neil Williams wrote:
> > > > 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.

You're not avoiding the build failures. The build failures are *caused by
the non-empty dependency_libs field*.

This is why the first step should be to try to empty out all the
dependency_libs fields, because this can be done archive-wide without
breaking anything.

> > 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.

Static linking didn't begin with libtool and doesn't end with it.
pkg-config is sufficient to handle the static linking use case for packages,
if those libraries support pkg-config.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org
 
Old 04-10-2011, 07:48 AM
Andreas Metzler
 
Default MBF: Getting rid of unneeded *.la / emptying dependency_libs

Neil Williams <codehelp@debian.org> wrote:
[...]

> With the caveats already covered in this thread (excepting kdelibs), are
> there objections to a MBF for this outdated Release Goal? We've already
> missed this Release Goal once, probably because no bugs were filed
> first time around.
[...]

Hello,
I have also tagged older related bug reports (My own, Steve Langasek's
and Andreas Moog's) and added a pointer to the wiki page. If you add
further bug reports please use user codehelp@debian.org usertags
la-file-removal.

cu andreas


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: ov3878-7pc.ln1@argenau.downhill.at.eu.org">http://lists.debian.org/ov3878-7pc.ln1@argenau.downhill.at.eu.org
 

Thread Tools




All times are GMT. The time now is 06:44 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org