Re: [PATCH 2/2] base: make feature backfilling happen earlier

[Phil Blundell <pb@pbcl.net>]

On Mon, 2013-01-28 at 16:44 +0100, Enrico Scholz wrote:
> afaik, DISTRO_FEATURES_BACKFILL + _CONSIDERED exist to allow the first
> two point without an '-=' operator which lacks in bitbake.

That wasn't really the intention.  The original purpose of
DISTRO_FEATURES_BACKFILL was to allow behaviour that currently defaults
to "on" to be brought under the control of a DISTRO_FEATURE without
breaking existing distros that were relying on it.

The idea was that DISTROs would set DISTRO_FEATURES_BACKFILL_CONSIDERED
to list the features that they are aware of but don't want (and would
never alter the value of DISTRO_FEATURES_BACKFILL).  Any feature that
ends up in the latter but not in the former is considered to post-date
the DISTRO and is, consequently, spliced into DISTRO_FEATURES by the
backwards-compatibility code.

Admittedly I'm not sure that this was ever documented anywhere other
than the mailing list archives so I guess it's understandable that you
(and quite likely others) are going a bit off-piste with it.  But the
primary use-case is what I described above, and this is the one that
needs to take precedence if there is a conflict between differing
requirements.

Incidentally, regarding your other comment about pulseaudio not
belonging in DISTRO_FEATURES_BACKFILL, it transpires that pulseaudio was
in fact the very feature that spurred the creation of this mechanism and
hence the first to be backfilled.  See:

http://thread.gmane.org/gmane.comp.handhelds.openembedded.core/10941/focus=13033

and the following thread.

p.