The portion that is not clear to me is why there is so much animosity against a var to enable .la files.
I find the folks commenting to be very technical. I trust that removing .la files is the right choice to make here. What I don't grok is when someone makes a statement like 'removing .la files will not break anything' or 'I understand exactly what affects this change will have on the entire tree and the affects are trivial.' I don't think any one person can make statements like that. The distribution is large, our userbase is large, and the risk is difficult to quantify. Because of the above, adding a toggle to roll back the change seems like a reasonable request. If the idea is to add a remove_la_files type function to eutils then the toggle can be added in a centralized place. If this change goes horribly awry and breaks the distribution (or some subset of users) everyone has an easy revert (set some envvar and rebuild everything...) What I do not want to see is editing thousands of ebuilds to 'rollback' the change. Nor do I want to see some complex procedure where we have to slip in a different implementation of remove_la_files to inhibit their deletion. The work to add a rollback trigger is all of 5 lines of bash; so why would we avoid adding it? -A On Mon, Oct 4, 2010 at 7:13 PM, Diego Elio Pettenò <flamee...@gmail.com> wrote: > 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/ > >
