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

[Duncan]

David Leverton posted on Sun, 03 Oct 2010 16:39:39 +0100 as excerpted:

> Also, not every piece of software that people might want to use is going
> to go into the main tree - people can use Gentoo to develop their own
> software (and might have their own ideas (or their company/project's
> ideas) about what parts of libtool it's appropriate to rely on), use
> packages from overlays, compile other people's software outside the
> package management system, run precompiled binaries, etc.  Again, from
> here I'm sure you can have a big discussion about whether libraries in
> the tree exist only to support applications in the tree, or whether
> they're "products" (for want of a better word) in their own right.

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, altho there's 
arguably a case that could be made for drawing the line /somewhat/ wider, 
say including official overlays as well, but even that very quickly 
becomes problematic as you're now expecting every dev with a candidate 
package to be familiar with every overlay it might affect.

No offense intended, and you do sort of make the point yourself with the 
"minor issue" thing, but arguably, this would be an /appropriate/ use of 
flameeyes' "people opposed are simply throwing up illegitimate blockages" 
complaint (where the binpkgs point wasn't, because that has long been a 
supported feature of Gentoo's primary PM and while breaking it may indeed 
be necessary, it's a legitimate point to raise).

OTOH, you do rightfully call it a minor point, perhaps one that shouldn't 
be a blocker, but one that should at least be raised.  Raising the point, 
minor and non-block tho it may be, in the discussion of record is a /good/ 
thing.  But I don't see how it's practical to do more than simply 
acknowledge it and say we can't let that block it (... except).

EXCEPT that the centralized controlling variable solution, via a removal 
method in EUTILS or the like, DOES make sense for any of a number of 
reasons, including that (a) centralizing the implementation is a good idea 
anyway, (b) once centralized, the implementation cost of a controlling 
variable is quite low, and (c), that makes it easy enough to control it 
either per-package or globally, using existing environment control 
solutions.

But beyond that, and for sub-package-level control, I simply don't see 
that it's practical.

But luckily, the above seems to fit your request as-is. =:^)  And as for 
sub-package-level, individual maintainers are still free to do what they 
believe is necessary with their packages, anyway.  (And for some packages 
and usages it /is/ arguably necessary.)

-- 
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