Re: [PROPOSAL] Package feature switches, redux.

[Chris Elston <celston@katalix.com>]

On Mon, 2011-07-04 at 14:58 +0100, Richard Purdie wrote:
> On Mon, 2011-07-04 at 12:54 +0100, Chris Elston wrote:
> > Since responses to my previous mail were generally positive, I've
> > reworked the package feature switches so that the interface is as RP
> > suggested.
> > 
> > In the recipe for foo you would have a set of features defined like
> > this:
> > 
> > PACKAGE_CONFIG[bar] = "--enable-bar, --disable-bar, libbar"
> > PACKAGE_CONFIG[baz] = "--enable-baz, --disable-baz, libbaz"
> > 
> > The default set of features for the package would be defined with:
> > 
> > PACKAGE_FEATURES ?= "bar baz" 
> > 
> > Perhaps this set of features could go into a metadata field in the .ipk
> > - would this be helpful for feed users?
> > 
> > The package features can then be tailored in a config/layer with
> > something like:
> > 
> > PACKAGE_FEATURES_pn-foo = "baz pop"
> > 
> > If a layer requests a feature not supported by the recipe, you get a
> > warning (should help distro maintainers detect bitrot in their layer):
> > 
> > WARNING: foo: Unknown feature 'pop' requested
> > 
> > The patch below uses gstreamer as an example of something which would
> > benefit from this:
> 
> Looks good, thanks.
> 
> My main concern is still the PACKAGE_FEATURES variable. I've been
> meaning to reply to your original email about this.
> 
> I understand your issue that you want to be able to do this on a per
> package basis. I suspect you also see my concern about maintain this
> centrally as a distro decision primarily rather than letting things
> descend into more of a free for all.


> FWIW, even if done centrally using DISTRO_FEATURES, you can customise on
> a per recipe basis if you ever needed to, e.g.:
> 
> DISTRO_FEATURES = "a b c ${MYDISTROTWEAKS}"
> MYDISTROTWEAKS = "d e f"
> MYDISTROTWEAKS_pn-gstreamer = "e"
> 
> Now I'd agree this is a bit ugly but I think it would encourage less
> misuse of the variable.

> Any thoughts on that?

Apologies for the delay in this response.  For those not present, we
discussed this a little on IRC the other day, and I'd like to resurrect
the on-list discussion.

I don't really understand the way in which you're worried it could be
misused if implemented as PACKAGE_FEATURES.  I'd imagined that
PACKAGE_FEATURES would have it's canonical setting in the recipe itself,
and would only be overridden in private layers.  I accept that my lack
of understanding is probably due to my inexperience with OE :)

I'm hopeful that we could find a technical solution that you're happy
won't cause maintenance problems down the line.

Cheers,

Chris.