public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Sebastian Pipping <sping@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] FEATURES use or misuse?
Date: Tue, 03 Nov 2009 18:27:46 +0100	[thread overview]
Message-ID: <4AF06812.9020406@gentoo.org> (raw)
In-Reply-To: <200911031648.04090.patrick@gentoo.org>

Patrick Lauer wrote:
> Hi there,
> 
> a while ago Thilo Bangert spent quite some time on filing lots of bugs. While 
> I appreciate such QA efforts I don't agree with those bugs at all.
> 
> 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.

What other methods are there?


> One example of such a bug is https://bugs.gentoo.org/show_bug.cgi?id=278960 
> for those too lazy to search.

For that very case I remember that "test" is a global use flag as well
and that therefore at least

  if hasq test ${FEATURES} ; then
      [..]
  fi

has a cleaner use-flag-based equivalent.

  # euse -i test
  global use flags (searching: test)
  ************************************************************
  [-    ] test - Workaround to pull in packages needed to run with
                 FEATURES=test. Portage-2.1.2 handles this internally,
                 so don't set it in make.conf/package.use anymore


> To quote:
> "FEATURES is a portage specific package manager configuration variable not
> specified in PMS and cannot reliably be used in ebuilds or eclasses."

Makes sense to me atm.


> Well then, I suggest we finally start documenting reality and fix PMS. The use 
> of the FEATURES variable, while it has been there for ... uhm ... as long as I 
> can think back, actually :), should not be randomly suppressed. 
> 
> So ... what's your opinion? Should we do things as they are correct, or as 
> they are specified in PMS? ( /me points at bash 3.0 )

My opinion is:  please stop dissing PMS, it doesn't help anybody.
I have requested that from you before.

Would a patch for the next EAPI theoretically impossible?



Sebastian



  reply	other threads:[~2009-11-03 17:27 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 [this message]
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

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=4AF06812.9020406@gentoo.org \
    --to=sping@gentoo.org \
    --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