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

Re: Old Release goal: Getting rid of unneeded *.la / emptying dependency_libs

On Sun, 03 Apr 2011 15:04:01 -0700
Russ Allbery <rra@debian.org> wrote:

> Neil Williams <codehelp@debian.org> writes:
> > 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.
> 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.

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

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

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

root@calvin:/home/libgpeschedule-0.17# cat debian/libgpeschedule-dev.install

# 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

Attachment: pgpXBDGQtj_11.pgp
Description: PGP signature

Reply to: