2012/1/17 Tom Rini <[email protected]>: > On Thu, Dec 29, 2011 at 5:55 AM, Paul Eggleton > <[email protected]> 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. > > I'm terrible at naming things so I guess backfill is as good as any (I > agree with Phil about introduce). Option a is clear so long as > there's a good comment, so lets go that way. > > -- > Tom > > _______________________________________________ > Openembedded-core mailing list > [email protected] > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Hi, just a quick question, couldn't we use a separate recipe for phonon, so if a recipe depends on it we don't have to change distro vars? To be honest, I haven't thought about the pro and contra about this. But as I am porting software that "needs" phonon and can't be patched to remove this need... IMHO it would be easier to just depend on libphonon.bb instead of adding a distro var for the one single recipe I'm working on. Just my 0.02 cents. By the way: KDE did this too: http://quickgit.kde.org/?p=phonon.git&a=summary -- Regards Samuel _______________________________________________ Openembedded-core mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
