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

[Alec Warner]

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ò <flameeyes@×××××.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/
>
>