public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Patrick Lauer <patrick@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] FEATURES use or misuse?
Date: Tue, 3 Nov 2009 21:36:18 +0100	[thread overview]
Message-ID: <200911032136.18242.patrick@gentoo.org> (raw)
In-Reply-To: <4AF06812.9020406@gentoo.org>

On Tuesday 03 November 2009 18:27:46 Sebastian Pipping wrote:
> 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?

For distcc, you could try some random things like checking the CC variable or 
such. All inherently unreliable methods to guess if the FEATURE variable 
contains a certain string.

Userpriv I've seen the funny idea to check if UID=0 and such. 

I'd guess for every FEATURE there's a similarly confused method to guess if it 
is enabled or disabled, instead of just checking the friggin variable.

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

That's a creative way to use a side-effect to check. Assumes that the package 
uses that useflag though, what about the case where you want to conditionally 
change a file (or maybe delete it or whatever) in src_prepare when 
FEATURES="test" is set, but USE="test" is not needed?

In short, stop complexifying things.

> 
> > 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.
Makes no sense to me, but then I seem to be special :)

> My opinion is:  please stop dissing PMS, it doesn't help anybody.
> I have requested that from you before.
It's still broken.
It doesn't document reality.
It's not useful as an implementation guideline or as a reference how to do 
things. In short, it sucks badly. And all my attempts to get it fixed have 
been deflected, so I'll keep ridiculing it until it stops being a failwhale.

After all I'm here to participate in the bestest distro ever, so we deserve 
correct and consistent documentation.
 
> Would a patch for the next EAPI theoretically impossible?
I absolutely fail to see how that helps the current situation.
EAPI is not the right answer to every question. :)


Have fun,

Patrick



  reply	other threads:[~2009-11-03 20:36 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 [this message]
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=200911032136.18242.patrick@gentoo.org \
    --to=patrick@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