Hear me out first of all: if I'm opening this bug it's because I've confirmed that some of the .la that your package installs are totally bogus: /usr/lib/perl5/site_perl/5.10.1/auto/Amanda/Types/libTypes.la /usr/lib/perl5/site_perl/5.10.1/auto/Amanda/Cmdline/libCmdline.la /usr/lib/perl5/site_perl/5.10.1/auto/Amanda/Xfer/libXfer.la /usr/lib/perl5/site_perl/5.10.1/auto/Amanda/Logfile/libLogfile.la /usr/lib/perl5/site_perl/5.10.1/auto/Amanda/Tests/libTests.la /usr/lib/perl5/site_perl/5.10.1/auto/Amanda/Debug/libDebug.la /usr/lib/perl5/site_perl/5.10.1/auto/Amanda/Application/libApplication.la /usr/lib/perl5/site_perl/5.10.1/auto/Amanda/Util/libUtil.la /usr/lib/perl5/site_perl/5.10.1/auto/Amanda/MainLoop/libMainLoop.la /usr/lib/perl5/site_perl/5.10.1/auto/Amanda/Config/libConfig.la /usr/lib/perl5/site_perl/5.10.1/auto/Amanda/Tapelist/libTapelist.la /usr/lib/perl5/site_perl/5.10.1/auto/Amanda/Archive/libArchive.la /usr/lib/perl5/site_perl/5.10.1/auto/Amanda/Device/libDevice.la These files are installed as either part of Ruby or Python bindings (neither interpreters use libtool to load their extensions, so they won't be even knowing the .la file is around, and you cannot *link* against those), or PAM modules (no implementation of PAM uses libtool to load the modules, so even here the .la files won't be considered at all). While these don't cause the kind of headaches .la files are known for (as you won't be linking against them to begin with), they are polluting the live filesystem as well as increasing the work for the analysis of those .la files that you link against. Please consider deleting them in the ebuild, after the make install is called. Further note: when these files are around, it's not uncommon for the packages to mistakenly build and install static archives (.a) files as well, even if these are modules that are only loaded from dynamic ELF files. If that is the case, *don't delete those after install*; instead follow the documentation I wrote at http://www.flameeyes.eu/autotools-mythbuster/libtool/index.html#libtool.plugins.dlopen to fix the packages so that only the shared object file is built (you still need to delete the .la file after install). This way you don't bother installing them and shorten the build time (as the static and shared versions are built with different flags which cause each source file to be built twice). Thank you for your help on cleaning up this mess. Diego
Actually, they're perl modules, but you're right - they're unused. If I knew a way to do this in automake, I'd do it upstream, but as it is, deleting the .la files in the ebuild is the right solution.
Heh I added Perl to the list and forgot to update the template, thanks! ;) Actually, you should probably look into the link anyway, as they seem to still build the static version as well (that you can stop in automake — unfortunately libtool files can't be non-installed, shitty libtool implementation I'd say).
I'll get the .la files for the plugins removed in the next release - thanks! BTW, diego, you might want to chagnge the phrase, "this mess," to something less judgemental. I read your blog and am familiar with the tinderbox, but even so it's a bit offensive to have my work dismissed as a "mess." May I suggest: "Thank you in advance for your help keeping packages up to Gentoo's high QA standards."
Uhm, I'm sorry if you felt I labelled that way your work. With “this mess” I definitely meant the mess created by .la files and their effect on users' system (“broken” packages).
No worries, just suggesting a template edit.
Fixed in 3.1.2-r1
