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
Cc: bangert@gentoo.org
Subject: Re: [gentoo-dev] a pragmatic approach to FEATURES [was FEATURES use or misuse?]
Date: Thu, 5 Nov 2009 01:36:18 -0800	[thread overview]
Message-ID: <20091105093618.GD25976@hrair> (raw)
In-Reply-To: <200911050949.10627.bangert@gentoo.org>

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

On Thu, Nov 05, 2009 at 09:49:07AM +0100, Thilo Bangert wrote:
> 
> > Perhaps the pragmatic approach might be wise.
> > 
> 
> when filing the FEATURES bugs, i (IIRC) tried to remain on the pragmatic 
> side, recognising the sometimes non-existing alternatives. ie. i didnt 
> open bugs for each and every FEATURES usage.
> 
> the tracker bug is here:
> http://bugs.gentoo.org/show_bug.cgi?id=174335

While I appreciate you being pragmatic in your cleanup efforts, you 
miss the point of my post- while FEATURES reliance needed a valid 
reason from a QA standpoint, it was *valid* from a format standpoint 
prior to paludis/PMS (and was the only option in some corner cases 
ebuild wise).

The response these days when it comes to FEATURES is that you cannot 
rely on it's existance ever- this loops back to my point about 
pragmatism.

I understand PMS/paludis wishing to duck the vars existance to make it 
go away, but I don't think it's a tenuable approach- as you yourself 
said above, in trying to do this cleanup you recognized that sometimes 
there was no alternative.

Please understand my point here is QA; not picking a fight.  That 
said, paludis doesn't do anything FEATURES wise due to PMS not 
mandating they do so... as you said, certain ebuilds rely on it's 
existance to work.

This means via PMS being incomplete, paludis isn't going to play nice 
in those cases (corner case- if the user defines the var themselves in 
their config, this would address it).

Essentially, you can't use FEATURES but you have to in some cases.  
Doing so however doesn't necessarily play nice w/ paludis due to 
stepping outside of PMS.  Classic catch 22.

Rather then letting the problem persist, I'd rather see folk take a 
look at FEATURES/PMS and identify what needs to be pushed in to take 
care of the cases where there is no alternative to 'hasq some-feature 
$FEATURES' rather then us just collectively sticking our heads in the 
sand.

Grok?

Or we can just keep ignoring the problem pretending it's a user config 
issue rather then a format level issue...
~harring

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

  reply	other threads:[~2009-11-05  9: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
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 [this message]
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=20091105093618.GD25976@hrair \
    --to=ferringb@gmail.com \
    --cc=bangert@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