Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Paul Eggleton <paul.eggleton@linux.intel.com>
To: openembedded-core@lists.openembedded.org
Cc: Koen Kooi <koen@dominion.thruhere.net>, Phil Blundell <philb@gnu.org>
Subject: Re: [PATCH 0/3] Make pulseaudio a DISTRO_FEATURE
Date: Mon, 16 Jan 2012 17:58:10 +0000	[thread overview]
Message-ID: <1427429.26ZIzxQgNj@helios> (raw)
In-Reply-To: <1412695.vvBBPeJL4B@helios>

On Thursday 29 December 2011 12:55:56 Paul Eggleton wrote:
> On Wednesday 23 November 2011 17:09:08 Richard Purdie wrote:
> > On Wed, 2011-11-23 at 16:48 +0000, Phil Blundell wrote:
> > > b) introduce some sort of concept of "feature epochs", where the
> > > DISTRO
> > > gets to declare what epoch it is expecting and the compatibility
> > > code
> > > then backfills DISTRO_FEATURES to take account of things that were
> > > enabled by default in past epochs but have since been removed.  This
> > > introduces a certain extra maintenance burden but it means that
> > > DISTROs
> > > will no longer get unpleasant surprises
> > 
> > I'm wondering if we can do something in the core like:
> > 
> > DISTRO_FEATURES_BACKFILLOPTS = "pulseaudio"
> > 
> > and have the distro set:
> > 
> > DISTRO_FEATURES_BACKFILLCONSIDERED = ""
> > 
> > and then add some code which looks for anything in
> > DISTRO_FEATURES_BACKFILLOPTS but not in
> > DISTRO_FEATURES_BACKFILLCONSIDERED and adds it to DISTRO_FEATURES.
> > 
> > Distros can then opt out of a given feature by adding it to
> > DISTRO_FEATURES_BACKFILLCONSIDERED.
> > 
> > This would let us maintain compatibility but also move forward and
> > create new settings with names that make sense.
> 
> I'd like to try to move forward with this fix (although I prefer an
> alternative term to "backfill", perhaps "introduce" instead?) If this is
> what we want to do, should it be implemented by:
> 
> (a) modifying DISTRO_FEATURES directly (as I think Richard is suggesting),
> or
> 
> (b) a simple python call that the distro needs to add to their own
> DISTRO_FEATURES (i.e. "${@distro_features_introduce(d)}" ?
> 
> Option (a) is a little tidier but (b) makes it obvious where any introduced
> items in DISTRO_FEATURES are coming from.

This was brought up at the last TSC meeting, but we agreed to leave the 
discussion on the mailing list for the moment.

So, any thoughts?

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre



  reply	other threads:[~2012-01-16 18:05 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-23 15:32 [PATCH 0/3] Make pulseaudio a DISTRO_FEATURE Paul Eggleton
2011-11-23 15:32 ` [PATCH 1/3] default-distrovars: add pulseaudio to DISTRO_FEATURES Paul Eggleton
2011-11-23 15:32 ` [PATCH 2/3] qt4: make pulseaudio support conditional upon DISTRO_FEATURES Paul Eggleton
2011-11-23 15:32 ` [PATCH 3/3] gst-plugins-good: " Paul Eggleton
2011-11-23 15:59 ` [PATCH 0/3] Make pulseaudio a DISTRO_FEATURE Koen Kooi
2011-11-23 16:33   ` Paul Eggleton
2011-11-23 16:48     ` Phil Blundell
2011-11-23 17:09       ` Richard Purdie
2011-11-23 17:45         ` Paul Eggleton
2011-11-23 17:49           ` Paul Eggleton
2011-11-23 17:53           ` Phil Blundell
2011-11-23 18:22             ` Otavio Salvador
2011-12-29 12:55         ` Paul Eggleton
2012-01-16 17:58           ` Paul Eggleton [this message]
2012-01-16 18:12             ` Phil Blundell
2012-01-17 23:13             ` Process for New DISTRO_FEATURES (was: Re: [PATCH 0/3] Make pulseaudio a DISTRO_FEATURE) Richard Purdie
2012-01-17 20:02           ` [PATCH 0/3] Make pulseaudio a DISTRO_FEATURE Tom Rini
2012-01-27 10:43             ` Samuel Stirtzel
2012-01-27 10:54               ` Paul Eggleton
2012-01-27 11:34                 ` Samuel Stirtzel
2012-01-27 12:13                   ` Paul Eggleton
2012-01-28 20:05                 ` Khem Raj

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=1427429.26ZIzxQgNj@helios \
    --to=paul.eggleton@linux.intel.com \
    --cc=koen@dominion.thruhere.net \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=philb@gnu.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