Il giorno sab, 02/10/2010 alle 19.54 +0000, Jorge Manuel B. S. Vicetto ha scritto: > > With that goal in mind, I'd like to ask anyone with arguments about > this > issue to present them as a reply to this thread.
I'm going instead to link my latest blog post on the matter where I summarised most of the points. Why a blog post? Because so I have it available as reference for the future together with all the others. Don't like that? Sorry, I don't care; I'm presenting information, if you choose to not even look at it because I serve it via HTTP rather than a mailing list, do state so; I'll make sure to ignore any of your opinions in the future. Now, stop with the less-than-friendly remarks, the content is at http://blog.flameeyes.eu/2010/10/04/libtool-archives-and-their-pointless-points 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". I might disagree with Nirbheek's assessment with the severity of the hit on users (or rather, on the relative severity of it compared with the alternative), but his reasoning is at least sound and based on real concerns. Things like "taking in account what isn't in the tree" (without actually having a clue on what .la files are for), looking for "alternative approaches" (to do what, exactly?), or "fixing what needs .la files" (why? if the package needs its own .la files to be around and nothing else, just leave it be!) are not concerns that I care about because they are not based on actual usefulness of .la files but on vague ideas of either fending off the finding of a solution (I don't want to know why, sincerely) or the idea that .la files are a binary situation where you shouldn't have any at all. 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). Other than that, do we really have a problem here? Nirbheek's point about stable will become moot next month; since we shouldn't revert the changes that did go to stable, we're left with two main issues here: - 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; - 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. On the other hand, I propose that if somebody have time on their hands (I sincerely don't, unless somebody's going to hire me to, and I'm dead serious), lafilefixer could be improved, and quick-stabled together with the new portage in case, so that it saves the modified metadata in the VDB. -- Diego Elio Pettenò — “Flameeyes” http://blog.flameeyes.eu/ If you found a .asc file in this mail and know not what it is, it's a GnuPG digital signature: http://www.gnupg.org/
signature.asc
Description: This is a digitally signed message part
