Discussion:
Old Release goal: Getting rid of unneeded *.la / emptying dependency_libs
(too old to reply)
Neil Williams
2011-04-03 10:53:02 UTC
Permalink
http://lists.debian.org/debian-devel/2009/08/msg00808.html

I'm now getting patches from Ubuntu to catch up the effects of this old
Release Goal. I fully support the removal of .la files [0] but it would
be good if we could refresh the original goal so that .la files can be
removed rather than applying a piece-meal set of patches to only
certain packages which have been spotted independently. That way leads
only to pain.

Let's try and handle the .la file issue across all of Debian.

Andreas: the process you used to create the initial list - is that
available as a script somewhere? Can it be re-run? Can the updated
output be filtered for the libraries which can have the .la files
removed immediately and then passed through dd-list?

(A dd-list using the above criteria and based on the OLD data is
attached - some packages listed in the original list no longer exist in
Debian and the rest of the packages have NOT been checked to see if
this has been done already. Just from my own data below, it's clear
that some packages have already completed the goal but will be listed
in the old data.)

If you are listed in the attached dd-list, it means that the following
tasks should be done REAL SOON NOW in order to smooth the path for
Multi-Arch and comply with Policy 10.2:

0: Check the listed package for .la files in the current version in sid.
1: Modify your package to DROP the .la file completely, if it remains.
2: Reply to this thread (whether you are changing your package or not)
so that any transitions can be managed.
3: File a bug against your own package if it hasn't been done already.
4: Check if there are other packages which have come to use your
package since the initial data was created.

My own data:
Neil Williams <***@debian.org>
libcontactsdb (U) #620444 - Drop .la file
libgpeschedule #620616 - .la file removal
libhandoff Needs a new bug report for .la file removal
libsoundgen #620618 - .la file removal
pilot-qof No .la file in sid.
tslib Needs a new bug report for .la file removal

(Filing those two bug reports myself currently).

This dd-list is NOT the complete data set from the OLD data, it is just
those packages which were listed as suitable for immediate removal of
the .la files back when the old data was originally generated. Since
that time, more packages have been changed and so more packages which
*were* listed as having dependencies possibly using these .la files may
now actually be candidates for removing the .la files.

It's a shame that the original MBF didn't get as far as actually filing
all the bugs or a lintian warning. I've already done a round of uploads
for these packages to clean up a range of other fixes and bugs. :-(
Ce la vie.

[0] http://lists.debian.org/debian-devel/2010/05/msg00014.html
--
Neil Williams
=============
http://www.linux.codehelp.co.uk/
Sune Vuorela
2011-04-03 11:38:58 UTC
Permalink
Post by Neil Williams
I'm now getting patches from Ubuntu to catch up the effects of this old
Release Goal. I fully support the removal of .la files [0] but it would
be good if we could refresh the original goal so that .la files can be
removed rather than applying a piece-meal set of patches to only
certain packages which have been spotted independently. That way leads
only to pain.
.la files themselves are harmless, if the dependency_libs field is
cleared.

There might be hard to replace old copies of libltdl in various code
pieces that can only open libraries/plugins with .la files. src:kdelibs
(which is about to be removed from debian) is one such example. I don't
know if there is others.


/Sune
Neil Williams
2011-04-03 11:47:02 UTC
Permalink
On Sun, 3 Apr 2011 11:38:58 +0000 (UTC)
Post by Sune Vuorela
Post by Neil Williams
I'm now getting patches from Ubuntu to catch up the effects of this old
Release Goal. I fully support the removal of .la files [0] but it would
be good if we could refresh the original goal so that .la files can be
removed rather than applying a piece-meal set of patches to only
certain packages which have been spotted independently. That way leads
only to pain.
.la files themselves are harmless, if the dependency_libs field is
cleared.
Harmless, but are they actually then useful?

It is far cleaner to simply not package the .la file than to mangle it
with sed in debian/rules - my contention is that removing the file is
the best solution to the harm done by the dependency_libs field.
Post by Sune Vuorela
There might be hard to replace old copies of libltdl in various code
pieces that can only open libraries/plugins with .la files. src:kdelibs
(which is about to be removed from debian) is one such example. I don't
know if there is others.
At least if we drop the low-hanging fruit of all the other packages
which package .la files without libltdl complications, it would be
easier to see if it is hard to replace old copies of libltdl or not.
--
Neil Williams
=============
http://www.linux.codehelp.co.uk/
Sune Vuorela
2011-04-03 12:05:34 UTC
Permalink
Post by Neil Williams
Post by Sune Vuorela
.la files themselves are harmless, if the dependency_libs field is
cleared.
Harmless, but are they actually then useful?
I just gave a example on where it is not only useful, but required.
Post by Neil Williams
Post by Sune Vuorela
There might be hard to replace old copies of libltdl in various code=20
pieces that can only open libraries/plugins with .la files. src:kdelibs
(which is about to be removed from debian) is one such example. I don't
know if there is others.
At least if we drop the low-hanging fruit of all the other packages
which package .la files without libltdl complications, it would be
easier to see if it is hard to replace old copies of libltdl or not.
I tried replacing the old copy of libltdl in kdelibs some years ago. I
got it easily building, but everything stopped working, I knew what to
do about getting everything working, but I ended up giving up because it
was too much work.

/Sune
Andreas Metzler
2011-04-03 17:49:22 UTC
Permalink
Neil Williams <***@debian.org> wrote:
[...]
Post by Neil Williams
It is far cleaner to simply not package the .la file than to mangle it
with sed in debian/rules - my contention is that removing the file is
the best solution to the harm done by the dependency_libs field.
[...]

Hello,
If you removed an la file that is listed in another's packages la file
dependency_libs, the other package would be broken. You'll need to
clean up the latter's dependency_libs / remove its la_lile *first.*
cu andreas
Neil Williams
2011-04-03 18:23:13 UTC
Permalink
On Sun, 3 Apr 2011 19:49:22 +0200
Post by Andreas Metzler
[...]
Post by Neil Williams
It is far cleaner to simply not package the .la file than to mangle it
with sed in debian/rules - my contention is that removing the file is
the best solution to the harm done by the dependency_libs field.
[...]
Hello,
If you removed an la file that is listed in another's packages la file
dependency_libs, the other package would be broken. You'll need to
clean up the latter's dependency_libs / remove its la_lile *first.*
cu andreas
That was part of the original Release Goal but, you're right, I left
that bit out of the original post. That's why the list starts with leaf
packages and related libraries.

The data used for my dd-list includes this part of the calculation. It
lists only those packages which would appear to not have any packages
using the .la file in question. That is why it is safe to remove
the .la file from any of the packages listed - AS LONG AS the
maintainer checks that no new packages have added the package as a
dependency since the data was generated.

This is also why the data needs to be re-generated. Not only are there
packages which are listed but which are already fixed, there are
packages which are listed as depending on the removal of .la files from
packages which are long fixed.
--
Neil Williams
=============
http://www.linux.codehelp.co.uk/
Mathieu Parent
2011-04-03 12:57:22 UTC
Permalink
Hi,
Post by Neil Williams
http://lists.debian.org/debian-devel/2009/08/msg00808.html
(...)
Post by Neil Williams
Let's try and handle the .la file issue across all of Debian.
dh-make 0.58 install .la files by default
(/usr/share/debhelper/dh_make/debianl/package-dev.install contains
"usr/lib/*.la")

Should we change this also?

Mathieu
Neil Williams
2011-04-03 14:48:22 UTC
Permalink
On Sun, 3 Apr 2011 14:57:22 +0200
Post by Mathieu Parent
Hi,
Post by Neil Williams
http://lists.debian.org/debian-devel/2009/08/msg00808.html
(...)
Post by Neil Williams
Let's try and handle the .la file issue across all of Debian.
dh-make 0.58 install .la files by default
(/usr/share/debhelper/dh_make/debianl/package-dev.install contains
"usr/lib/*.la")
This is about "unneeded" .la files. As Sune points out, there are some
situations where it is more work to remove the .la file than it is
worth. So it isn't a blanket removal, it is about getting a consistent
approach across Debian so that issues like the one Sune describes can
be more clearly identified.

dh_make does not set the defaults in Debian. Maintainers must make
their own decisions about which bits of a dh_make setup deserve to be
retained in their packaging of that package, according to Policy.
Policy 10.2 is the discussion point here. Since Policy 10.2 was last
updated, Multi-Arch has changed the "penalty" for getting this bit of
Policy wrong.

This is about identifying .la files which can be removed to make
things easier in Multi-Arch world.
Post by Mathieu Parent
Should we change this also?
It is possible that a lintian warning can be arranged to indicate when
it might be unhelpful to package the .la file but that is no different
to lots of other bits of dh_make which are created at initial packaging
but which later need removal or adjustment.
--
Neil Williams
=============
http://www.linux.codehelp.co.uk/
Goswin von Brederlow
2011-04-03 21:06:17 UTC
Permalink
Post by Mathieu Parent
Hi,
Post by Neil Williams
http://lists.debian.org/debian-devel/2009/08/msg00808.html
(...)
Post by Neil Williams
Let's try and handle the .la file issue across all of Debian.
dh-make 0.58 install .la files by default
(/usr/share/debhelper/dh_make/debianl/package-dev.install contains
"usr/lib/*.la")
Should we change this also?
Mathieu
I think we should. Since this is about new packages let it start without
an .la file. If the file is really needed (which should be rare for new
stuff) people will notice. On the other hand if it is included by
default people will just leave it in there.

MfG
Goswin
Emilio Pozuelo Monfort
2011-04-05 17:02:08 UTC
Permalink
Package: dh-make
Severity: wishlist

Hi,
Post by Mathieu Parent
dh-make 0.58 install .la files by default
(/usr/share/debhelper/dh_make/debianl/package-dev.install contains
"usr/lib/*.la")
Should we change this also?
Since policy discourages shipping .la files, and there's a release goal for
that, please stop adding *.la files in libfoo-dev.install. It can be manually
added in the rare cases where it's really required.

Thanks,
Emilio
Andreas Metzler
2011-04-03 17:45:13 UTC
Permalink
Neil Williams <***@debian.org> wrote:
[...]
Post by Neil Williams
I'm now getting patches from Ubuntu to catch up the effects of this old
Release Goal. I fully support the removal of .la files [0] but it would
be good if we could refresh the original goal so that .la files can be
removed rather than applying a piece-meal set of patches to only
certain packages which have been spotted independently. That way leads
only to pain.
Let's try and handle the .la file issue across all of Debian.
Andreas: the process you used to create the initial list - is that
available as a script somewhere? Can it be re-run? Can the updated
output be filtered for the libraries which can have the .la files
removed immediately and then passed through dd-list?
[...]

Afaiu the script output http://release.debian.org/~aba/la/current.txt
is automatically updated. e.g. libvmime (fixed 2011-03-07) is not
included anymore.

Combine the script output with
http://lists.debian.org/debian-devel/2009/08/msg00808.html
to get up-to-date instructions.

cu andreas
Neil Williams
2011-04-03 18:41:36 UTC
Permalink
On Sun, 3 Apr 2011 19:45:13 +0200
Post by Andreas Metzler
Post by Neil Williams
Andreas: the process you used to create the initial list - is that
available as a script somewhere? Can it be re-run? Can the updated
output be filtered for the libraries which can have the .la files
removed immediately and then passed through dd-list?
[...]
Afaiu the script output http://release.debian.org/~aba/la/current.txt
is automatically updated. e.g. libvmime (fixed 2011-03-07) is not
included anymore.
Thanks. Should have checked that URL - it's moved from ftp-master.d.o.
Post by Andreas Metzler
Combine the script output with
http://lists.debian.org/debian-devel/2009/08/msg00808.html
to get up-to-date instructions.
To generate the dd-list, I've used:
$ wget http://release.debian.org/~aba/la/current.txt
$ grep -v depended-on current.txt |cut -d: -f1|xargs dd-list > ddlist.txt

That dd-list is attached from today's data.

My updated info:

Neil Williams <***@debian.org>
gpe-expenses (waiting for bug number)
libcontactsdb (U) #620444
libgpeschedule #620616
libhandoff #620655
libsoundgen #620618
tslib #620658
--
Neil Williams
=============
http://www.linux.codehelp.co.uk/
Russ Allbery
2011-04-03 22:04:01 UTC
Permalink
Post by Neil Williams
If you are listed in the attached dd-list, it means that the following
tasks should be done REAL SOON NOW in order to smooth the path for
0: Check the listed package for .la files in the current version in sid.
1: Modify your package to DROP the .la file completely, if it remains.
You cannot just drop *.la files completely in every case. Software that
uses libltdl to load dynamic objects often loads those objects by the *.la
file name (and hence is documented that way in upstream documentation,
FAQs, and so forth), so we create gratuitous incompatibilities with
upstream if we drop those *.la files. It's also not necessary since there
isn't a multi-arch issue.

Policy 10.2 doesn't say to remove all *.la files. It says:

Packages that use libtool to create and install their shared libraries
install a file containing additional metadata (ending in .la)
alongside the library. For public libraries intended for use by other
packages, these files normally should not be included in the Debian
package, since the information they include is not necessary to link
with the shared library on Debian and can add unnecessary additional
dependencies to other programs or libraries. If the .la file is
required for that library (if, for instance, it's loaded via libltdl
in a way that requires that meta-information), the dependency_libs
setting in the .la file should normally be set to the empty string. If
the shared library development package has historically included the
.la, it must be retained in the development package (with
dependency_libs emptied) until all libraries that depend on it have
removed or emptied dependency_libs in their .la files to prevent
linking with those other libraries using libtool from failing.

I still believe all those caveats are important.

For example, shibboleth-sp2 was in your list because it has loadable
modules in the libapache2-mod-shib2 package:

/usr/lib/shibboleth/adfs-lite.la
/usr/lib/shibboleth/adfs-lite.so
/usr/lib/shibboleth/adfs.la
/usr/lib/shibboleth/adfs.so
/usr/lib/shibboleth/odbc-store.la
/usr/lib/shibboleth/odbc-store.so

This is already Policy 10.2-compliant and will not cause problems with
multi-arch since those modules and their *.la files are arch-dependent and
will get separate installs on 32-bit and 64-bit paths if needed.

Lintian already checks that *.la files don't contain the problematic
dependency_libs setting.
--
Russ Allbery (***@debian.org) <http://www.eyrie.org/~eagle/>
Neil Williams
2011-04-04 07:38:59 UTC
Permalink
On Sun, 03 Apr 2011 15:04:01 -0700
Post by Russ Allbery
Post by Neil Williams
If you are listed in the attached dd-list, it means that the following
tasks should be done REAL SOON NOW in order to smooth the path for
0: Check the listed package for .la files in the current version in sid.
1: Modify your package to DROP the .la file completely, if it remains.
You cannot just drop *.la files completely in every case.
The cases listed are the ones where the .la file can be removed.
Packages with .la files which don't meet those criteria were not
included in the list. However, it looks like there could be a flaw in
the original data.
Post by Russ Allbery
Software that
uses libltdl to load dynamic objects often loads those objects by the *.la
file name (and hence is documented that way in upstream documentation,
FAQs, and so forth), so we create gratuitous incompatibilities with
upstream if we drop those *.la files. It's also not necessary since there
isn't a multi-arch issue.
Packages that use libtool to create and install their shared libraries
install a file containing additional metadata (ending in .la)
alongside the library. For public libraries intended for use by other
packages, these files normally should not be included in the Debian
package, since the information they include is not necessary to link
with the shared library on Debian and can add unnecessary additional
dependencies to other programs or libraries. If the .la file is
required for that library (if, for instance, it's loaded via libltdl
in a way that requires that meta-information), the dependency_libs
setting in the .la file should normally be set to the empty string. If
the shared library development package has historically included the
.la, it must be retained in the development package (with
dependency_libs emptied) until all libraries that depend on it have
removed or emptied dependency_libs in their .la files to prevent
linking with those other libraries using libtool from failing.
I still believe all those caveats are important.
As do I. The processing which leads to the list implements those
caveats. The ones listed should fall into the category:

"until all libraries that depend on it have removed or emptied
dependency_libs in their .la files to prevent linking with those other
libraries using libtool from failing."

That is why lines in the original data described as "depended-on" are
omitted.
Post by Russ Allbery
For example, shibboleth-sp2 was in your list because it has loadable
/usr/lib/shibboleth/adfs-lite.la
/usr/lib/shibboleth/adfs-lite.so
/usr/lib/shibboleth/adfs.la
/usr/lib/shibboleth/adfs.so
/usr/lib/shibboleth/odbc-store.la
/usr/lib/shibboleth/odbc-store.so
This is already Policy 10.2-compliant and will not cause problems with
multi-arch since those modules and their *.la files are arch-dependent and
will get separate installs on 32-bit and 64-bit paths if needed.
OK, maybe there's a problem there. 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?
Post by Russ Allbery
Lintian already checks that *.la files don't contain the problematic
dependency_libs setting.
In a clean pbuilder sid chroot:

dpkg-genchanges >../libgpeschedule_0.17-3_i386.changes
dpkg-genchanges: not including original source code in upload
dpkg-source --after-build libgpeschedule-0.17
dpkg-buildpackage: binary and diff upload (original source NOT included)
Now running lintian...
warning: lintian's authors do not recommend running it with root privileges!
W: libgpeschedule source: debhelper-but-no-misc-depends libgpeschedule0-dbg
W: libgpeschedule source: ancient-standards-version 3.7.3 (current is 3.9.1)
W: libgpeschedule0-dbg: wrong-section-according-to-package-name libgpeschedule0-dbg => debug
Finished running lintian.

No warning from current lintian from sid, yet #620616 indicates that
there is a problematic .la file here - and indeed it is currently
deliberately installed.

***@calvin:/home/libgpeschedule-0.17# cat debian/libgpeschedule-dev.install
debian/tmp/usr/lib/libgpeschedule.la
debian/tmp/usr/lib/libgpeschedule.a
debian/tmp/usr/lib/pkgconfig/libgpeschedule.pc
debian/tmp/usr/lib/libgpeschedule.so
debian/tmp/usr/include/gpe/schedule.h

# Libraries that this one depends upon.
dependency_libs=' /usr/lib/libsqlite.la -lpthread
-lgpewidget /usr/lib/libgtk-x11-2.0.la /usr/lib/libgdk-x11-2.0.la /usr/lib/libatk-1.0.la /usr/lib/libgio-2.0.la /usr/lib/libpangoft2-1.0.la /usr/lib/libpangocairo-1.0.la /usr/lib/libgdk_pixbuf-2.0.la
-lm /usr/lib/libcairo.la
-lpng12 /usr/lib/libpango-1.0.la /usr/lib/libfreetype.la
-lfontconfig /usr/lib/libgobject-2.0.la /usr/lib/libgmodule-2.0.la /usr/lib/libgthread-2.0.la
-lrt /usr/lib/libglib-2.0.la'

Maybe there's something here that lintian isn't catching, maybe this is
just something which is a result of the Multi-Arch requirements. Either
way, this is a .la file which has generated a bug report, it is not
currently picked up by lintian and it is not covered by the criteria in
Policy 10.2, AFAICT.

So lintian isn't getting this right either.
--
Neil Williams
=============
http://www.linux.codehelp.co.uk/
Russ Allbery
2011-04-04 17:49:04 UTC
Permalink
Post by Neil Williams
The cases listed are the ones where the .la file can be removed.
Packages with .la files which don't meet those criteria were not
included in the list. However, it looks like there could be a flaw in
the original data.
Indeed, there were a bunch of different problems, although mostly with my
understanding.
Post by Neil Williams
shibboleth-sp2: dependency_libs links-not-existing-la
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.
Post by Neil Williams
Post by Russ Allbery
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.
--
Russ Allbery (***@debian.org) <http://www.eyrie.org/~eagle/>
Neil Williams
2011-04-04 18:33:24 UTC
Permalink
On Mon, 04 Apr 2011 10:49:04 -0700
Post by Russ Allbery
Post by Neil Williams
shibboleth-sp2: dependency_libs links-not-existing-la
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.
Post by Russ Allbery
Post by Neil Williams
Post by Russ Allbery
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/
Steve Langasek
2011-04-04 23:12:42 UTC
Permalink
Post by Neil Williams
Post by Russ Allbery
Post by Russ Allbery
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/
***@ubuntu.com ***@debian.org
Neil Williams
2011-04-05 07:41:37 UTC
Permalink
On Mon, 4 Apr 2011 16:12:42 -0700
Post by Steve Langasek
Post by Neil Williams
Post by Russ Allbery
Post by Russ Allbery
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.
Post by Steve Langasek
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/
Steve Langasek
2011-04-07 06:50:38 UTC
Permalink
Post by Neil Williams
Post by Steve Langasek
Post by Neil Williams
Post by Russ Allbery
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.
Post by Neil Williams
Post by Steve Langasek
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/
***@ubuntu.com ***@debian.org
Andreas Metzler
2011-04-10 07:48:40 UTC
Permalink
Neil Williams <***@debian.org> wrote:
[...]
Post by Neil Williams
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 ***@debian.org usertags
la-file-removal.

cu andreas

Steve Langasek
2011-04-04 00:06:18 UTC
Permalink
Hi Neil,
Post by Neil Williams
http://lists.debian.org/debian-devel/2009/08/msg00808.html
I'm now getting patches from Ubuntu to catch up the effects of this old
Release Goal. I fully support the removal of .la files [0] but it would
be good if we could refresh the original goal so that .la files can be
removed rather than applying a piece-meal set of patches to only
certain packages which have been spotted independently. That way leads
only to pain.
Let's try and handle the .la file issue across all of Debian.
Thanks for raising this topic on debian-devel.

The bug reports you've seen are the result of me working through the set of
libraries whose .la files were broken when the initial multiarch library set
landed in Ubuntu. Given that this release goal is a couple of years old and
the recommendation is also in Policy for a while now, the degree of .la file
breakage here is not something I had expected; roughly 170 libraries in
total had references to .la files for core libraries that were invalidated
by the move to multiarch, so we've been burning through these as quickly as
possible (and forwarding patches upstream to Debian) to ensure Ubuntu
remains buildable from source for the natty release.

Now that this is largely out of the way, we should definitely look at a more
general and scalable solution than filing patches against each package with
a .la file.

In addition to changing dh-make to not install .la files by default, as has
already been suggested in this thread, I think we should look to get the
desired behavior out of the common helpers (dh and cdbs) by default. As a
first pass, taking into account all the caveats Russ has pointed out from
Policy 10.2, I think we should get these helpers to strip out
dependency_libs which AFAIK is safe for all uses. Once that's made its way
through the archive, we could consider going further and avoid shipping .la
files in /usr/lib at all by default.

I exclude classic debhelper from the reckoning here, because I don't see
that such .la file cleaning fits well in any of the existing dh_ tools (it
would probably be unexpected to have, say, dh_makeshlibs suddenly start
editing .la files), so we can probably only pick this up automatically for
packages that use a common helper for their debhelper command sequencing.
--
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/
***@ubuntu.com ***@debian.org
Cyril Brulebois
2011-04-04 00:19:43 UTC
Permalink
Post by Steve Langasek
In addition to changing dh-make to not install .la files by default,
as has already been suggested in this thread, I think we should look
to get the desired behavior out of the common helpers (dh and cdbs)
by default.
As a guy who added something like the following in several dozens of
packages, I can tell you I'd be more than happy if $stuff would do the
job for me (unless told not to):
| # Kill *.la files, and forget no-one:
| override_dh_install:
| find debian/tmp -name '*.la' -delete
| dh_install --fail-missing

I have no useful idea to share about the practical implementation, but
for the general idea:
Acked-by: Cyril Brulebois <***@debian.org>

KiBi.
Cyril Brulebois
2011-04-04 01:19:52 UTC
Permalink
I might be mistaken, but I think Steve's meant something more along
the lines of http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=586082
I guess I could have been more specific, and quoted Steve a bit
further:
| Once that's made its way through the archive, we could consider
| going further and avoid shipping .la files in /usr/lib at all by
| default.

(If /usr/lib was meant to be that directory only and no subdirectory,
I guess I would suggest amending that proposal with some
subdirectories “known to be safe for .la removal”, like /usr/lib/xorg/
and subdirectories below.)

KiBi.
Michael Biebl
2011-04-04 01:12:21 UTC
Permalink
Post by Cyril Brulebois
Post by Steve Langasek
In addition to changing dh-make to not install .la files by default,
as has already been suggested in this thread, I think we should look
to get the desired behavior out of the common helpers (dh and cdbs)
by default.
As a guy who added something like the following in several dozens of
packages, I can tell you I'd be more than happy if $stuff would do the
| find debian/tmp -name '*.la' -delete
| dh_install --fail-missing
I have no useful idea to share about the practical implementation, but
I might be mistaken, but I think Steve's meant something more along the lines of
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=586082
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
Josselin Mouette
2011-04-04 02:49:41 UTC
Permalink
Post by Steve Langasek
Now that this is largely out of the way, we should definitely look at a more
general and scalable solution than filing patches against each package with
a .la file.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=534966
--
.''`.
: :' : “You would need to ask a lawyer if you don't know
`. `' that a handshake of course makes a valid contract.”
`- -- J???rg Schilling
Continue reading on narkive:
Loading...