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 omitted. > 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 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/
Attachment:
pgpXBDGQtj_11.pgp
Description: PGP signature