public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Brian Harring <ferringb@gmail.com>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev]  Re: FEATURES use or misuse?
Date: Wed, 4 Nov 2009 21:04:01 -0800	[thread overview]
Message-ID: <20091105050401.GC25976@hrair> (raw)
In-Reply-To: <1257372724.5846.26.camel@lillen.dodi>

[-- Attachment #1: Type: text/plain, Size: 2001 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

      reply	other threads:[~2009-11-05  5:04 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-03 15:48 [gentoo-dev] FEATURES use or misuse? Patrick Lauer
2009-11-03 17:27 ` Sebastian Pipping
2009-11-03 20:36   ` Patrick Lauer
2009-11-03 20:58     ` Ciaran McCreesh
2009-11-03 22:28       ` Patrick Lauer
2009-11-04  0:11         ` [gentoo-dev] " Ryan Hill
2009-11-04  8:26           ` Patrick Lauer
2009-11-05  1:36             ` Ryan Hill
2009-11-05  4:56               ` [gentoo-dev] a pragmatic approach to FEATURES [was FEATURES use or misuse?] Brian Harring
2009-11-05  8:49                 ` Thilo Bangert
2009-11-05  9:36                   ` Brian Harring
2009-11-08  9:21                     ` Thilo Bangert
2009-11-03 21:26 ` [gentoo-dev] FEATURES use or misuse? Alexis Ballier
2009-11-03 22:04   ` Patrick Lauer
2009-11-03 22:26     ` Ciaran McCreesh
2009-11-04  0:33     ` Sebastian Pipping
2009-11-04  8:26       ` Patrick Lauer
2009-11-03 23:04 ` David Leverton
2009-11-04  1:31   ` [gentoo-dev] " Duncan
2009-11-04 22:12 ` Peter Hjalmarsson
2009-11-05  5:04   ` Brian Harring [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20091105050401.GC25976@hrair \
    --to=ferringb@gmail.com \
    --cc=gentoo-dev@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox