* Diego Elio Pettenò <[email protected]> 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: +49 36207 519931 email: [email protected] mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 ---------------------------------------------------------------------- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme ----------------------------------------------------------------------
