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

[Russ Allbery <rra@debian.org>]

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.  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 (rra@debian.org)               <http://www.eyrie.org/~eagle/>