On Sun, 2 May 2010 13:17:08 +0400 "Nikita V. Youshchenko" <yoush@debian.org> wrote: > I'm going to unload a new version, and, among other things, I was > going to remove .la file, per release-goal (Thanks for the reminder, the lack of a bug report led to me completely forgetting that I meant to do something about this goal for my own packages.) (Not having .la files that need mangling with dpkg-cross would make cross-building easier too - apart from the .pc files, the rest of the dpkg-cross changes would just be moving files around, not modifying them. One less thing to go wrong, so I'm in favour of removing .la files generally. Simply removing the contents of dependency_libs isn't as good - it the .la is an issue, remove all of it IMHO.) > In http://ftp-master.debian.org/~aba/la/current.txt, package is > listed as 'libetpan: dependency_libs', so I thoughty I just need to > remove .la file from -dev package > > However I'm confused with how this interfers with static linking > support. I've seen talks on this in list archives, but no > project-scope resolution. In the discussion that led to the release goal: "It might happen that we come to the conclusion that we need to keep a few la-files around, as they might be a help for static compiling, but static compiling is at best "not the default", so I would be quite surprised if that's more than 5-10 files (and then that's the exception that confirms the rule)." http://lists.debian.org/debian-devel/2009/08/msg00783.html That's about as resolved as it got AFAICT. Static linking is generally discouraged, ergo static linking support is expendable if such support gets in the way of more useful things, like binNMUs - which it does. > libetpan-dev depends on several other -dev packages because libraries > from those are mentioned in dependency_libs, and because libraries > provided by those -dev packages are needed to link statically against > libetpan. But does any package in Debian actually do the static linking? > So, should I: > > (1) just drop .la file, or > (2) drop .la file, downgrade dependences on -dev packages to > recommends: or suggests:, or > (3) drop .la file and dependences on -dev packages, but keep > libetpan.a, or > (4) drop .la file and dependences on -dev packages and libetpan.a > > Perhaps (4) is the most consistent solution, since nobody cares about > static linking these days. However AFAIU debian's policy is still to > provide static libraries. 8.3 - The static library (libraryname.a) is usually provided in addition to the shared version. That reads more like Policy documenting usual practice rather than mandating that static linking is necessarily desirable or should be explicitly supported even if it causes issues elsewhere. > (3) looks like plain inconsistency: package will provide .a file, but > not ensure things required for using .a file into system. > So I likely should choose from (1) and (2). Removing the .la and retaining the .a is useful because? (To actually statically link without the .la (or with an .la 'mangled' to empty the dependency_libs field) largely amounts to reconstructing the information that was in the .la originally. That should be sufficient disincentive to try to statically link at all. Hence, is it worth wasting archive space on the inevitably much larger .a files?) Personally, I'm thinking of dropping static support in the Debian packages by removing the .la and the .a but preserving dependencies where needed for shared library builds (i.e. Requires: in the .pc file, not Requires.private, where my library directly exports symbols in it's own API that are resolved in another shared library.) -- Neil Williams ============= http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/
Attachment:
pgptZ_RkdUx1S.pgp
Description: PGP signature