From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mga01.intel.com ([192.55.52.88]) by linuxtogo.org with esmtp (Exim 4.72) (envelope-from ) id 1RgFdb-0000zh-8H for openembedded-core@lists.openembedded.org; Thu, 29 Dec 2011 14:03:15 +0100 Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga101.fm.intel.com with ESMTP; 29 Dec 2011 04:55:59 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="106977691" Received: from unknown (HELO helios.localnet) ([10.252.122.61]) by fmsmga002.fm.intel.com with ESMTP; 29 Dec 2011 04:55:58 -0800 From: Paul Eggleton To: openembedded-core@lists.openembedded.org Date: Thu, 29 Dec 2011 12:55:56 +0000 Message-ID: <1412695.vvBBPeJL4B@helios> Organization: Intel Corporation User-Agent: KMail/4.7.3 (Linux/3.0.0-14-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <1322068148.15626.15.camel@ted> References: <1322066940.26081.27.camel@phil-desktop> <1322068148.15626.15.camel@ted> MIME-Version: 1.0 Cc: Koen Kooi , Phil Blundell Subject: Re: [PATCH 0/3] Make pulseaudio a DISTRO_FEATURE X-BeenThere: openembedded-core@lists.openembedded.org X-Mailman-Version: 2.1.11 Precedence: list Reply-To: Patches and discussions about the oe-core layer List-Id: Patches and discussions about the oe-core layer List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2011 13:03:15 -0000 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre