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

[Duncan]

Richard Freeman posted on Mon, 04 Oct 2010 11:19:29 -0400 as excerpted:

> On 10/03/2010 09:26 PM, Duncan wrote:
>> The problem is that "in-tree" is a reasonably bounded set of builds,
>> while "out-of-tree" is unlimited.  Practically speaking, I simply don't
>> see how Gentoo can be concerned with "out-of-tree" in general.
>
> If any other distro had that attitude Gentoo (and other source-based
> distros) would be the only ones that provided packages for GCC, since no
> other distro requires a functioning toolchain to install packages.

Interesting viewpoint.  But I disagree that it is so.  Rather, for binary 
distros, while gcc and the rest of the toolchain may not be /required/ for 
user-side maintenance of the distribution itself, they're certainly 
packages that provide a specific set of functionality.  As such, they're 
included in general distributions where such functionality may be desired, 
for much the same reason KDE or LAMP are included -- they are useful 
enough for a wide enough segment of the userbase to justify inclusion.  
OTOH, more specialized distributions may not include them, because they're 
simply not needed for the designated target usage.

In gentoo-speak, binary distributions include toolchain packages not as 
part of @system, but for those who wish to use them in their @world.

If Gentoo were therefore to take a binary distro approach, we'd do split-
packages.  Much as the binary distros have package-x and package-x-dev 
(which I'd guess include the *.la files, BTW), we'd have package-x and 
package-x-la, or some such.

Of course, the gentoo version of that is USE flags, FEATURES, etc.  Which 
means we're "in violent agreement!" =:^) and brings us back to...

> I like the USE flag proposal because it lets us have our cake and eat it
> too.  Those who don't need .la files don't get them except where
> absolutely essential, and those who need and are willing to live with
> tons of them can have it their way.
>
> Gentoo is about choice...

The key-variable (whether USE flag, FEATURE, or a bit more hidden) based 
trigger does seem the pragmatic solution here.

Flameeyes, yes, I understand your objection to it on technical grounds as 
unnecessary complexity.  And I freely admit I'm not technically astute 
enough (in reality, probably few Gentoo devs are, with certain noted 
exceptions, of course) to debate you on the merits, there.  On the 
technical side, AFAIAC [1] you win by stipulation.

But there's more to life than being technically correct.  A centralized
la-file-stripper implementation seems to make sense in any case, and once 
it's centralized, exposing a control variable for it is little additional 
trouble.  Given the choice between allowing for the control variable in 
ordered to establish the necessary consensus and getting it deployed in 
months, vs either continuing to debate it for years or simply steamrolling 
it thru without that option, whatever the technical merits, I agree with 
rich0, the control variable seems the /clear/ winner, here.

Assuming that's the way it ultimately goes, what remains is to settle on 
the nature of the control variable.  There are merits in something 
slightly hidden, but OTOH, the USE flag idea has merits of its own.  It 
seems to me that the usual solution in similar cases is a USE flag, but 
masked.  So count this as a vote for a masked USE flag. =:^)

---
[1] AFAIAC: As Far as I am concerned:
http://www.onelook.com/cgi-bin/cgiwrap/bware/dofind.cgi?word=AFAIAC

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman