On Wed, Nov 04, 2009 at 11:12:05PM +0100, Peter Hjalmarsson wrote:
> tis 2009-11-03 klockan 16:48 +0100 skrev Patrick Lauer:
> > Hi there,
> > 
> > All of these bugs were for the use of the FEATURES variable in ebuilds, which 
> > is a very convenient thing to work around issues. 
> > For example known failures with FEATURE="distcc" or funky things like test 
> > failures with FEATURES="userpriv" and so on. All other methods of expressing 
> > that are much more verbose and inherently sucky.
> 
> I ask myself if what we really want is many different and strange
> approaches to handle FEATURES?
> Would it not be better to actually expand some eclasses to be able to
> say something about your build environment?

This is a *really* bad approach- pkgcore/paludis have supported 
standalone repositories basically from their inception, portage (via 
repos.conf) has developed equivalent support, and from the looks of it 
is moving towards such capabilities.

What this means is that eclasses aren't automatically mashed together 
across all trees and shared.  Meaning each repository would have to 
carry those eclasses, or require that they always be slaved against a 
specific repository carrying said eclasses (again, bad mojo).

The code duplication there is annoying, but the potential range of 
screwups this can lead to is even worse.  Further, via proper 
environment saving/restoration for installed pkgs/binpkgs, this means 
that one screwed up FEATURES detection (or that things have changed 
since then and a new check is required) lives on forever, no 
possibility of being updated/fixed in the env dump.

Shorter version, eclasses are a fun idea at first until you dig in and 
realize they'll blow your leg off for things like this.

If it's any consolation, I proposed moving large chunks of eapi0 
(prior to eapi existing) into the tree- the idea died off for the same 
reasons your "FEATURE awareness in eclasses" must die off.

~harring