Patchwork base.bbclass: Add support to EXTRA_DISTRO_FEATURES

login
register
mail settings
Submitter Otavio Salvador
Date July 29, 2013, 10:26 p.m.
Message ID <1375136787-18139-1-git-send-email-otavio@ossystems.com.br>
Download mbox | patch
Permalink /patch/54745/
State New
Headers show

Comments

Otavio Salvador - July 29, 2013, 10:26 p.m.
This allow the addition and removal of distro features easily. To add
a feature, use:

 EXTRA_DISTRO_FEATURES += "wayland"

and to remove, use '~' prefix, as:

 EXTRA_DISTRO_FEATURES += "~x11"

This code has been mostly copied from Mentor Graphics public layer but
changed the variable name for a more descriptive name. The original
code can be seen at user_feature.bbclass at:

 http://git.yoctoproject.org/cgit/cgit.cgi/meta-mentor

Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
---
 meta/classes/base.bbclass |  4 ++++
 meta/lib/oe/utils.py      | 20 ++++++++++++++++++++
 2 files changed, 24 insertions(+)
Otavio Salvador - July 29, 2013, 10:35 p.m.
Hello Eric and Rogerio,

On Mon, Jul 29, 2013 at 7:26 PM, Otavio Salvador
<otavio@ossystems.com.br> wrote:
> This allow the addition and removal of distro features easily. To add
> a feature, use:
>
>  EXTRA_DISTRO_FEATURES += "wayland"
>
> and to remove, use '~' prefix, as:
>
>  EXTRA_DISTRO_FEATURES += "~x11"
>
> This code has been mostly copied from Mentor Graphics public layer but
> changed the variable name for a more descriptive name. The original
> code can be seen at user_feature.bbclass at:
>
>  http://git.yoctoproject.org/cgit/cgit.cgi/meta-mentor
>
> Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>

I have submitted a patch for OE-Core to address this hardness to
add/remove distro features. It is based in user_features.bbclass from
Metro Graphics but I changed it to fit better in base.bbclass. Please
give it a try and comment if you have a better alternative solution
for this problem.

--
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://projetos.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750
Rogerio Nunes - July 29, 2013, 10:57 p.m.
Thank you, Otavio!

On Mon, Jul 29, 2013 at 6:35 PM, Otavio Salvador
<otavio@ossystems.com.br> wrote:
> Hello Eric and Rogerio,
>
> On Mon, Jul 29, 2013 at 7:26 PM, Otavio Salvador
> <otavio@ossystems.com.br> wrote:
>> This allow the addition and removal of distro features easily. To add
>> a feature, use:
>>
>>  EXTRA_DISTRO_FEATURES += "wayland"
>>
>> and to remove, use '~' prefix, as:
>>
>>  EXTRA_DISTRO_FEATURES += "~x11"
>>
>> This code has been mostly copied from Mentor Graphics public layer but
>> changed the variable name for a more descriptive name. The original
>> code can be seen at user_feature.bbclass at:
>>
>>  http://git.yoctoproject.org/cgit/cgit.cgi/meta-mentor
>>
>> Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
>
> I have submitted a patch for OE-Core to address this hardness to
> add/remove distro features. It is based in user_features.bbclass from
> Metro Graphics but I changed it to fit better in base.bbclass. Please
> give it a try and comment if you have a better alternative solution
> for this problem.
>
> --
> Otavio Salvador                             O.S. Systems
> http://www.ossystems.com.br        http://projetos.ossystems.com.br
> Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
Paul Eggleton - July 30, 2013, 10:59 a.m.
On Monday 29 July 2013 19:26:27 Otavio Salvador wrote:
> This allow the addition and removal of distro features easily. To add
> a feature, use:
> 
>  EXTRA_DISTRO_FEATURES += "wayland"
> 
> and to remove, use '~' prefix, as:
> 
>  EXTRA_DISTRO_FEATURES += "~x11"
> 
> This code has been mostly copied from Mentor Graphics public layer but
> changed the variable name for a more descriptive name. 

1) Isn't this just adding list subtraction via the back door, which Richard 
has already argued against (mostly because the interaction between it and 
_append/_prepend will be hard to predict)?

2) Why not just set DISTRO_FEATURES to contain just the items you want in your 
distro configuration instead of trying to add and subtract from some previous 
value? What if the previous value changes in a way that no longer fits your 
desired configuration? Surely it is better to just be explicit.

3) Even if we were to add this here wouldn't users expect this to work in all 
such variables and not just DISTRO_FEATURES?

Cheers,
Paul
Otavio Salvador - July 30, 2013, noon
On Tue, Jul 30, 2013 at 7:59 AM, Paul Eggleton
<paul.eggleton@linux.intel.com> wrote:
> On Monday 29 July 2013 19:26:27 Otavio Salvador wrote:
>> This allow the addition and removal of distro features easily. To add
>> a feature, use:
>>
>>  EXTRA_DISTRO_FEATURES += "wayland"
>>
>> and to remove, use '~' prefix, as:
>>
>>  EXTRA_DISTRO_FEATURES += "~x11"
>>
>> This code has been mostly copied from Mentor Graphics public layer but
>> changed the variable name for a more descriptive name.
>
> 1) Isn't this just adding list subtraction via the back door, which Richard
> has already argued against (mostly because the interaction between it and
> _append/_prepend will be hard to predict)?

We call it and /finalize/ the database so it has _append/_prepend
resolved before mangling the list.

> 2) Why not just set DISTRO_FEATURES to contain just the items you want in your
> distro configuration instead of trying to add and subtract from some previous
> value? What if the previous value changes in a way that no longer fits your
> desired configuration? Surely it is better to just be explicit.

To make this, we cannot reuse Poky distro for example as it
/unconditionally/ appends to DISTRO_FEATURES. Besides it is easier for
test to be able to override it using local.conf. For products I agree
we'll end adding a distro to make it reprodicable but for development
stage this trick makes life much easier.

> 3) Even if we were to add this here wouldn't users expect this to work in all
> such variables and not just DISTRO_FEATURES?

I did this for DISTRO_FEATURES and I don't think it is good to have
this for all vars.

--
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://projetos.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750
Phil Blundell - July 30, 2013, 12:14 p.m.
On Tue, 2013-07-30 at 09:00 -0300, Otavio Salvador wrote:
> To make this, we cannot reuse Poky distro for example as it
> /unconditionally/ appends to DISTRO_FEATURES. Besides it is easier for
> test to be able to override it using local.conf. For products I agree
> we'll end adding a distro to make it reprodicable but for development
> stage this trick makes life much easier.

Surely for one-off tests you can just write out the whole intended value
of DISTRO_FEATURES in your local.conf.  It doesn't seem as though this
variable is unwieldy enough that it really needs mechanical handling.

As for poky appending to DISTRO_FEATURES rather than just setting it,
that sounds like it's arguably a bug in poky and you should perhaps take
it up with those guys.  Of course, they might take the view that poky
itself is meant to be determining what DISTRO_FEATURES it wants and they
don't want to support or encourage random frobbing of flags by third
parties, and I think that'd be an understandable position.

>We call it and /finalize/ the database so it has _append/_prepend
>resolved before mangling the list.

That seems a bit unwholesome in itself.  Are you sure there are no
potential bad consequences from calling finalize() there?

p.
Otavio Salvador - July 30, 2013, 12:24 p.m.
On Tue, Jul 30, 2013 at 9:14 AM, Phil Blundell <pb@pbcl.net> wrote:
> On Tue, 2013-07-30 at 09:00 -0300, Otavio Salvador wrote:
>> To make this, we cannot reuse Poky distro for example as it
>> /unconditionally/ appends to DISTRO_FEATURES. Besides it is easier for
>> test to be able to override it using local.conf. For products I agree
>> we'll end adding a distro to make it reprodicable but for development
>> stage this trick makes life much easier.
>
> Surely for one-off tests you can just write out the whole intended value
> of DISTRO_FEATURES in your local.conf.  It doesn't seem as though this
> variable is unwieldy enough that it really needs mechanical handling.
>
> As for poky appending to DISTRO_FEATURES rather than just setting it,
> that sounds like it's arguably a bug in poky and you should perhaps take
> it up with those guys.  Of course, they might take the view that poky
> itself is meant to be determining what DISTRO_FEATURES it wants and they
> don't want to support or encourage random frobbing of flags by third
> parties, and I think that'd be an understandable position.
>
>>We call it and /finalize/ the database so it has _append/_prepend
>>resolved before mangling the list.
>
> That seems a bit unwholesome in itself.  Are you sure there are no
> potential bad consequences from calling finalize() there?

No; I am not sure. What I know is it has been being used by meta-metro
and O.S. Systems distribution without issues for a while and it solves
the problem I have.

Adding /full/ distro features list is ugly and easy to get wrong. This
seems much better for user IMO.

--
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://projetos.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750
Mark Hatle - July 30, 2013, 2:46 p.m.
On 7/30/13 7:24 AM, Otavio Salvador wrote:
> On Tue, Jul 30, 2013 at 9:14 AM, Phil Blundell <pb@pbcl.net> wrote:
>> On Tue, 2013-07-30 at 09:00 -0300, Otavio Salvador wrote:
>>> To make this, we cannot reuse Poky distro for example as it
>>> /unconditionally/ appends to DISTRO_FEATURES. Besides it is easier for
>>> test to be able to override it using local.conf. For products I agree
>>> we'll end adding a distro to make it reprodicable but for development
>>> stage this trick makes life much easier.
>>
>> Surely for one-off tests you can just write out the whole intended value
>> of DISTRO_FEATURES in your local.conf.  It doesn't seem as though this
>> variable is unwieldy enough that it really needs mechanical handling.
>>
>> As for poky appending to DISTRO_FEATURES rather than just setting it,
>> that sounds like it's arguably a bug in poky and you should perhaps take
>> it up with those guys.  Of course, they might take the view that poky
>> itself is meant to be determining what DISTRO_FEATURES it wants and they
>> don't want to support or encourage random frobbing of flags by third
>> parties, and I think that'd be an understandable position.
>>
>>> We call it and /finalize/ the database so it has _append/_prepend
>>> resolved before mangling the list.
>>
>> That seems a bit unwholesome in itself.  Are you sure there are no
>> potential bad consequences from calling finalize() there?
>
> No; I am not sure. What I know is it has been being used by meta-metro
> and O.S. Systems distribution without issues for a while and it solves
> the problem I have.
>
> Adding /full/ distro features list is ugly and easy to get wrong. This
> seems much better for user IMO.

I agree with the previous folks that the design of the distribution setting the 
one and true value is the right technical answer for this.  HOWEVER, in my 
experience, this is NOT what end users want.

They want a method similar to the one posted by Otavio in order to tailor the 
system.  End users never want to create a new distribution, they simply want to 
start with one and tweak it.

So with that said, my opinion is to enable this code, allowing end users to 
tweak their distribution settings.  But make it a stated policy that 
distribution layers should only "set" the value of DISTRO_FEATURES, and should 
never modify/update this new EXTRA_DISTRO_FEATURES value.  (Of course, I doubt 
there is a way to police that, other then state it's policy.)

This is the same type of reason that end users was a "don't install this 
package" feature as well.  While anyone can write a new image recipe, nobody 
wants to, especially when they only want one or two less packages in their image.

--Mark

> --
> Otavio Salvador                             O.S. Systems
> http://www.ossystems.com.br        http://projetos.ossystems.com.br
> Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
Paul Eggleton - July 30, 2013, 3:09 p.m.
On Tuesday 30 July 2013 09:46:19 Mark Hatle wrote:
> I agree with the previous folks that the design of the distribution setting
> the one and true value is the right technical answer for this.  HOWEVER, in
> my experience, this is NOT what end users want.
> 
> They want a method similar to the one posted by Otavio in order to tailor
> the system.  End users never want to create a new distribution, they simply
> want to start with one and tweak it.

Then surely an easier solution would be to advocate copy-and-modify of an 
existing distro config, and if we're not setting the value of DISTRO_FEATURES 
explicitly there (which we aren't currently in poky.conf) then we should just 
do that in order to make that easier?

I honestly think building on an existing configuration value that is not 
immediately visible and might change when the user upgrades to a new version 
of the underlying distro is not a good thing to be encouraging people to do.

> So with that said, my opinion is to enable this code, allowing end users to
> tweak their distribution settings.  But make it a stated policy that
> distribution layers should only "set" the value of DISTRO_FEATURES, and
> should never modify/update this new EXTRA_DISTRO_FEATURES value.  (Of
> course, I doubt there is a way to police that, other then state it's
> policy.)

Yes but people will just ignore that. DISTRO_FEATURES_BACKFILL has already 
been abused for similar purposes :/

> This is the same type of reason that end users was a "don't install this
> package" feature as well. While anyone can write a new image recipe, nobody
> wants to, especially when they only want one or two less packages in their
> image.

Surely the primary motivation for having the "remove" functionality [1] is the 
case when you don't know how a particular package has got in via dependencies 
and you want it removed, and not the percieved difficulty of creating an image 
recipe?

Really if people write nothing else they should be writing their own image 
recipes, because it's trivially easy to do so (or at the very least, copy an 
existing one and modify it).

[1] https://bugzilla.yoctoproject.org/show_bug.cgi?id=4079

Cheers,
Paul
Phil Blundell - July 30, 2013, 3:19 p.m.
On Tue, 2013-07-30 at 09:46 -0500, Mark Hatle wrote:
> They want a method similar to the one posted by Otavio in order to tailor the 
> system.  End users never want to create a new distribution, they simply want to 
> start with one and tweak it.

They can already do that by overriding the distro's own DISTRO_FEATURES
in local.conf (modulo poky's alleged _append thing), and/or by copying
and hacking the distro.conf file itself.  And, of course, any distro
which intends itself to be explicitly end-user-tweakable like this is
welcome to include a mechanism like Otavio's one in their own layer.

> So with that said, my opinion is to enable this code, allowing end users to 
> tweak their distribution settings.  But make it a stated policy that 
> distribution layers should only "set" the value of DISTRO_FEATURES, and should 
> never modify/update this new EXTRA_DISTRO_FEATURES value.  (Of course, I doubt 
> there is a way to police that, other then state it's policy.)

Both end-users and distro maintainers already have enough trouble
understanding what the interactions are between the different variables
and who's meant to be setting which ones (see DISTRO_FEATURES_BACKFILL
for example which seems to be fairly frequently misunderstood).  Adding
extra complexity to what is already a fraught area seems like a bad
plan.

> This is the same type of reason that end users was a "don't install this 
> package" feature as well.  While anyone can write a new image recipe, nobody 
> wants to, especially when they only want one or two less packages in their image.

End users already have BAD_RECOMMENDATIONS for that, right?  And
courtesy Paul's recent changes I think this now even works for the
rpm-using fraternity.

p.
Mark Hatle - July 30, 2013, 3:37 p.m.
On 7/30/13 10:09 AM, Paul Eggleton wrote:
> On Tuesday 30 July 2013 09:46:19 Mark Hatle wrote:
>> I agree with the previous folks that the design of the distribution setting
>> the one and true value is the right technical answer for this.  HOWEVER, in
>> my experience, this is NOT what end users want.
>>
>> They want a method similar to the one posted by Otavio in order to tailor
>> the system.  End users never want to create a new distribution, they simply
>> want to start with one and tweak it.
>
> Then surely an easier solution would be to advocate copy-and-modify of an
> existing distro config, and if we're not setting the value of DISTRO_FEATURES
> explicitly there (which we aren't currently in poky.conf) then we should just
> do that in order to make that easier?
>
> I honestly think building on an existing configuration value that is not
> immediately visible and might change when the user upgrades to a new version
> of the underlying distro is not a good thing to be encouraging people to do.

I don't disagree with you either, but my experience so far is end users don't 
care.  They also don't know what the right setting(s) should be.  So they are 
more comfortable with adding or removing individual options.

>> So with that said, my opinion is to enable this code, allowing end users to
>> tweak their distribution settings.  But make it a stated policy that
>> distribution layers should only "set" the value of DISTRO_FEATURES, and
>> should never modify/update this new EXTRA_DISTRO_FEATURES value.  (Of
>> course, I doubt there is a way to police that, other then state it's
>> policy.)
>
> Yes but people will just ignore that. DISTRO_FEATURES_BACKFILL has already
> been abused for similar purposes :/
>
>> This is the same type of reason that end users was a "don't install this
>> package" feature as well. While anyone can write a new image recipe, nobody
>> wants to, especially when they only want one or two less packages in their
>> image.
>
> Surely the primary motivation for having the "remove" functionality [1] is the
> case when you don't know how a particular package has got in via dependencies
> and you want it removed, and not the percieved difficulty of creating an image
> recipe?

That is part of it.. but it's the same concept.  The end user doesn't have any 
desire to learn recipe's, image generation, etc.  So they want a path of least 
resistance.  I don't want 'foo', so remove it.  (When I say remove BTW, I'm 
really mean don't install..  vs install -then- remove.)

> Really if people write nothing else they should be writing their own image
> recipes, because it's trivially easy to do so (or at the very least, copy an
> existing one and modify it).

I don't disagree with you, but the two commercial (oe-core based) releases I've 
been involved with over the last couple years, the yelling keeps getting louder 
for a removal capability, because they don't want to write image recipes.

--Mark

> [1] https://bugzilla.yoctoproject.org/show_bug.cgi?id=4079
>
> Cheers,
> Paul
>
Mark Hatle - July 30, 2013, 3:43 p.m.
On 7/30/13 10:19 AM, Phil Blundell wrote:
> On Tue, 2013-07-30 at 09:46 -0500, Mark Hatle wrote:
>> They want a method similar to the one posted by Otavio in order to tailor the
>> system.  End users never want to create a new distribution, they simply want to
>> start with one and tweak it.
>
> They can already do that by overriding the distro's own DISTRO_FEATURES
> in local.conf (modulo poky's alleged _append thing), and/or by copying
> and hacking the distro.conf file itself.  And, of course, any distro
> which intends itself to be explicitly end-user-tweakable like this is
> welcome to include a mechanism like Otavio's one in their own layer.

Unfortunately we may have to include functionality like this to address this 
problem.  But deviating from oe-core has potentially significant maintenance 
issues, especially long-term.

Reality is this is functionality that I've been asked for multiple time in the 
last year or so, and I've stated back "don't do that".  To which the end user 
(my customer) has said that isn't acceptable.

So I'd advocate this, or similar functionality is definitely desired by a class 
of users (many less knowledgeable about Linux distribution design), even though 
I do agree it's not the right way to do it.  (The whole concept of the 
distribution settings being 'variable' without a new distribution configuration 
file is incorrect to me.)

>> So with that said, my opinion is to enable this code, allowing end users to
>> tweak their distribution settings.  But make it a stated policy that
>> distribution layers should only "set" the value of DISTRO_FEATURES, and should
>> never modify/update this new EXTRA_DISTRO_FEATURES value.  (Of course, I doubt
>> there is a way to police that, other then state it's policy.)
>
> Both end-users and distro maintainers already have enough trouble
> understanding what the interactions are between the different variables
> and who's meant to be setting which ones (see DISTRO_FEATURES_BACKFILL
> for example which seems to be fairly frequently misunderstood).  Adding
> extra complexity to what is already a fraught area seems like a bad
> plan.
>
>> This is the same type of reason that end users was a "don't install this
>> package" feature as well.  While anyone can write a new image recipe, nobody
>> wants to, especially when they only want one or two less packages in their image.
>
> End users already have BAD_RECOMMENDATIONS for that, right?  And
> courtesy Paul's recent changes I think this now even works for the
> rpm-using fraternity.

That only filters out recommendations though.  A good example is some x86 
packagegroups have a requirement of 'vte'.  It turns out a class of end users 
don't want 'vte'.  And they have no easy way to remove it.  Telling them to 
generate a new image, with a custom IMAGE_INSTALL value that includes everything 
except 'vte' doesn't make sense to them.

(The bad_recommendations thing is sorely needed as well to help prevent the "why 
the hell did this get there" problem as well..)

--Mark

> p.
>
>
Phil Blundell - July 30, 2013, 4:05 p.m.
On Tue, 2013-07-30 at 10:43 -0500, Mark Hatle wrote:
> That only filters out recommendations though.  A good example is some x86 
> packagegroups have a requirement of 'vte'.  It turns out a class of end users 
> don't want 'vte'.  And they have no easy way to remove it.  Telling them to 
> generate a new image, with a custom IMAGE_INSTALL value that includes everything 
> except 'vte' doesn't make sense to them.

I'm not familiar with the particular example that you mentioned, but it
sounds as though the packagegroups in question ought to be recommending
vte rather than depending on it.  I think this is probably true for
packagegroup dependencies in general in fact.

The intended semantics of RDEPENDS are that anything named in that list
is absolutely required for correct operation and can't be removed
without breaking the functionality of the package that's doing the
depending.  Things that are desirable but not absolutely necessary
should be in RRECOMMENDS (and can be suppressed with
BAD_RECOMMENDATIONS), and things which are entirely optional but might
be "nice to have" should be in RSUGGESTS.

p.
Otavio Salvador - July 30, 2013, 9 p.m.
On Tue, Jul 30, 2013 at 1:05 PM, Phil Blundell <pb@pbcl.net> wrote:
> On Tue, 2013-07-30 at 10:43 -0500, Mark Hatle wrote:
>> That only filters out recommendations though.  A good example is some x86
>> packagegroups have a requirement of 'vte'.  It turns out a class of end users
>> don't want 'vte'.  And they have no easy way to remove it.  Telling them to
>> generate a new image, with a custom IMAGE_INSTALL value that includes everything
>> except 'vte' doesn't make sense to them.
>
> I'm not familiar with the particular example that you mentioned, but it
> sounds as though the packagegroups in question ought to be recommending
> vte rather than depending on it.  I think this is probably true for
> packagegroup dependencies in general in fact.
>
> The intended semantics of RDEPENDS are that anything named in that list
> is absolutely required for correct operation and can't be removed
> without breaking the functionality of the package that's doing the
> depending.  Things that are desirable but not absolutely necessary
> should be in RRECOMMENDS (and can be suppressed with
> BAD_RECOMMENDATIONS), and things which are entirely optional but might
> be "nice to have" should be in RSUGGESTS.

--
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://projetos.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750
Otavio Salvador - July 30, 2013, 9:01 p.m.
On Tue, Jul 30, 2013 at 1:05 PM, Phil Blundell <pb@pbcl.net> wrote:
> On Tue, 2013-07-30 at 10:43 -0500, Mark Hatle wrote:
>> That only filters out recommendations though.  A good example is some x86
>> packagegroups have a requirement of 'vte'.  It turns out a class of end users
>> don't want 'vte'.  And they have no easy way to remove it.  Telling them to
>> generate a new image, with a custom IMAGE_INSTALL value that includes everything
>> except 'vte' doesn't make sense to them.
>
> I'm not familiar with the particular example that you mentioned, but it
> sounds as though the packagegroups in question ought to be recommending
> vte rather than depending on it.  I think this is probably true for
> packagegroup dependencies in general in fact.
>
> The intended semantics of RDEPENDS are that anything named in that list
> is absolutely required for correct operation and can't be removed
> without breaking the functionality of the package that's doing the
> depending.  Things that are desirable but not absolutely necessary
> should be in RRECOMMENDS (and can be suppressed with
> BAD_RECOMMENDATIONS), and things which are entirely optional but might
> be "nice to have" should be in RSUGGESTS.

I think we're getting off-topic here. I think we ought to focus in
distro-features discussion here and handle package installs in another
thread.

--
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://projetos.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Patch

diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
index 9c92e0b..83f6458 100644
--- a/meta/classes/base.bbclass
+++ b/meta/classes/base.bbclass
@@ -298,6 +298,9 @@  def buildcfg_neededvars(d):
     if pesteruser:
         bb.fatal('The following variable(s) were not set: %s\nPlease set them directly, or choose a MACHINE or DISTRO that sets them.' % ', '.join(pesteruser))
 
+EXTRA_DISTRO_FEATURES ?= ""
+EXTRA_DISTRO_FEATURES[type] = "list"
+
 addhandler base_eventhandler
 base_eventhandler[eventmask] = "bb.event.ConfigParsed bb.event.BuildStarted"
 python base_eventhandler() {
@@ -307,6 +310,7 @@  python base_eventhandler() {
         preferred_ml_updates(e.data)
         oe.utils.features_backfill("DISTRO_FEATURES", e.data)
         oe.utils.features_backfill("MACHINE_FEATURES", e.data)
+        oe.utils.extra_distro_features(e.data)
 
     if isinstance(e, bb.event.BuildStarted):
         localdata = bb.data.createCopy(e.data)
diff --git a/meta/lib/oe/utils.py b/meta/lib/oe/utils.py
index 82987e8..9e82801 100644
--- a/meta/lib/oe/utils.py
+++ b/meta/lib/oe/utils.py
@@ -117,6 +117,26 @@  def features_backfill(var,d):
     if addfeatures:
         d.appendVar(var, " " + " ".join(addfeatures))
 
+def extra_distro_features(d):
+    import oe.data
+
+    extra_features = oe.data.typed_value('EXTRA_DISTRO_FEATURES', d)
+    if not extra_features:
+        return
+
+    d.finalize()
+
+    distro_features = d.getVar('DISTRO_FEATURES', True).split()
+    for feature in extra_features:
+        if feature.startswith('~'):
+            feature = feature[1:]
+            if feature in distro_features:
+                distro_features.remove(feature)
+        else:
+            if feature not in distro_features:
+                distro_features.append(feature)
+
+    d.setVar('DISTRO_FEATURES', ' '.join(distro_features))
 
 def packages_filter_out_system(d):
     """