On Mon, 30 May 2011 12:23:35 +0200 Vincent Lefevre <vincent@vinc17.net> wrote: > On 2011-05-27 00:17:45 +0200, Michael Biebl wrote: > > Am 26.05.2011 23:26, schrieb Luk Claes: > > > > > There are some good reasons to keep some specific *.la files around, > > > > Just curious: what are these reasons / use case for keeping la files? > > They are at least read by libtool. That is why dependency_libs can be cleared unconditionally but removal of the .la file itself needs to be done in a sequence where the leaf libraries have their .la files removed first, then the packages which those .la files would have referenced. This is the depended_on listing in the original analysis data: http://release.debian.org/~aba/la/current.txt Packages which are listed with a "depended_on" listing must not remove the .la file until those dependencies remove their .la files or clear their dependency_libs setting in the .la file. At that point, the file above will list that package as "dependency_libs" only. libtool will fail if a required .la file is not present - it will not fail if the required .la file is present but has an empty dependency_libs field. Equally, libtool is happy to not need any .la files when dependency_libs fields are all empty. Arguably this utilises a weakness in libtool in that it trusts the contents of the .la file too much, thinking that it is the same content as libtool itself wrote out originally. Once all the dependency_libs are clear, any package not using .la files for plugin loading can then remove their .la files without breaking any other package in the archive. The .la files then (finally) become package-specific and have no impact on other packages. The problem with .la files in Debian is that the data in the .la file is inherently outdated as it is only completely regenerated when every single package in the archive is rebuilt in a specific sequence. There are simpler ways of updating dependency information. libtool's method just doesn't suit what Debian requires. > Either the information provided by /usr/lib/libgmp.la is important > and this file should be kept, or libtool should not attempt to read > the file... unless this doesn't matter for the specific case of > /usr/lib under Debian. libtool will not attempt to read the .la file of the next level of dependencies if the dependency_libs field of the immediate dependencies are empty. Compare: $ grep 'dependency_libs=' /usr/lib/*.la Where the output lists explicit file paths (like /usr/lib/libpangoft2-1.0.la) then those listings need to be removed by clearing the entire dependency_libs field. The package build process in Debian deals with providing the information in ways which are controllable within the single package build instead of using, what is essentially, archived data from previous builds as is preserved in the .la files of dependencies. -- Neil Williams ============= http://www.linux.codehelp.co.uk/
Attachment:
pgpdni0PX10Su.pgp
Description: PGP signature