Re: [gentoo-dev] Re: .la files and their future on Gentoo

[Enrico Weigelt]

* Diego Elio Pettenò <flameeyes@×××××.com> schrieb:

> http://blog.flameeyes.eu/2010/10/04/libtool-archives-and-their-pointless-points

ACK.

IMHO, removing the .la files should be under invididual ebuild
(or eclass) control, and we also should try to get it fixed 
at the source (if possible).

> Also, I would like to ask again that if you're going to argue "you never
> know who might use them", you're going to have to actually understand
> _what_ the files are used for, _which_ software uses them, and come up
> with a use case for them, not a vague "oh there might be a project that
> use them".

That whole "you'll never know who might use them"-idea is a bad idea,
IMHO. By that doctrine you can never get rid of old crap. Sometimes
an cut has to be made.

And for Distros, it doesnt make sense to try to support anything imaginable.
Instead there's limited (yet large) set of packages that are supported.
We can track the dependencies and so know who's using some particular
package (inside the distro). So we can actually test if removing la-files
from one invidual package will break anything. Maybe it's even worth
to make an automatic testsuite.

> From my point of view, the only points worth to be raised are Nirbheek's
> (even though I disagree, as I said), Rémi's (which I don't think he
> either considers showstoppers at this point) and those not-yet-spoken
> off by Prefix (they might support architectures where .la files are
> worth something).

Are there any platforms where .la files are really worth anything ?
(in Gentoo's scope) ? And *if* there're some - could there be better
solutions ?

BTW: In general, the idea of having a metadata file per library is
quite nice. (if done well, even better than the pkg-config approach).
But libtool implements this particular bad - it doesnt have a proper
abstraction (actually, libtool is not an abstraction at all, as eg.
unitool does, but just an command line filter doing mysterious things).

*If* someone here really likes the per-library-metadata idea, then
let's start an own project for that (knowing that'll be just reasearch
and not production-grade for quite some time). But that yet goes far
off-scope of distros (until a reasonable amount of packages adopted it).

>  - is it okay to drop them from stable? my personal opinion here is to
> side with Samuli and say "yes"; on the other hand, since by the looks of
> it, and the status report Zac gave us, we're going to need just one
> extra month before just telling users "install lafilefixer and update to
> stable portage 2.1.9.13", I think we can avoid doing any more of those
> changes till then ??? in stable that is; this includes both non-revbumps
> and stable requests of packages dropping them;

Admitting I've not fully followed this thread, but IMHO portage changes
aren't needed here - just put the la-skipping/-removal into individual
ebuilds. Portage can provide generic functions for that later, which
then can be used by newer ebuilds, but doesnt need to.

>  - what about Rémi's 2b concern? Sincerely I have worked for a long time
> with static linking on my job and I don't see libtool files being so
> excessively necessary; the only problem comes with transitive
> dependencies, but most packages already take care of that; even if you
> do not use pkg-config, you have other means to recover it.

I'm now working in embedded area (where static linking is quite common)
for about 10yrs, and pkg-config has proven quite well here. (packages
that dont provide .pc-descriptor yet, simply have to be fixed to do
so ;-p). Libtool, on the other hand, always had been a nightmare.


cu
-- 
----------------------------------------------------------------------
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  [phone]  email: weigelt@×××××.de
 mobile: [phone]  icq:   210169427         skype: nekrad666
----------------------------------------------------------------------
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------