* [PATCH] base.bbclass: Add support to EXTRA_DISTRO_FEATURES
@ 2013-07-29 22:26 Otavio Salvador
2013-07-29 22:35 ` Otavio Salvador
2013-07-30 10:59 ` Paul Eggleton
0 siblings, 2 replies; 18+ messages in thread
From: Otavio Salvador @ 2013-07-29 22:26 UTC (permalink / raw)
To: OpenEmbedded Core Mailing List; +Cc: Otavio Salvador
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(+)
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):
"""
--
1.8.3.2
^ permalink raw reply related [flat|nested] 18+ messages in thread
* Re: [PATCH] base.bbclass: Add support to EXTRA_DISTRO_FEATURES
2013-07-29 22:26 [PATCH] base.bbclass: Add support to EXTRA_DISTRO_FEATURES Otavio Salvador
@ 2013-07-29 22:35 ` Otavio Salvador
2013-07-30 10:59 ` Paul Eggleton
1 sibling, 0 replies; 18+ messages in thread
From: Otavio Salvador @ 2013-07-29 22:35 UTC (permalink / raw)
To: OpenEmbedded Core Mailing List
Cc: meta-freescale@yoctoproject.org, Eric Nelson, Rogerio Nunes
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] base.bbclass: Add support to EXTRA_DISTRO_FEATURES
@ 2013-07-29 22:35 ` Otavio Salvador
0 siblings, 0 replies; 18+ messages in thread
From: Otavio Salvador @ 2013-07-29 22:35 UTC (permalink / raw)
To: OpenEmbedded Core Mailing List
Cc: meta-freescale@yoctoproject.org, Rogerio Nunes, Saul Wold
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] base.bbclass: Add support to EXTRA_DISTRO_FEATURES
2013-07-29 22:35 ` Otavio Salvador
@ 2013-07-29 22:57 ` Rogerio Nunes
-1 siblings, 0 replies; 18+ messages in thread
From: Rogerio Nunes @ 2013-07-29 22:57 UTC (permalink / raw)
To: Otavio Salvador
Cc: meta-freescale@yoctoproject.org, Eric Nelson, Rogerio Nunes,
OpenEmbedded Core Mailing List
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [OE-core] [PATCH] base.bbclass: Add support to EXTRA_DISTRO_FEATURES
@ 2013-07-29 22:57 ` Rogerio Nunes
0 siblings, 0 replies; 18+ messages in thread
From: Rogerio Nunes @ 2013-07-29 22:57 UTC (permalink / raw)
To: Otavio Salvador
Cc: meta-freescale@yoctoproject.org, Rogerio Nunes,
OpenEmbedded Core Mailing List
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [OE-core] [PATCH] base.bbclass: Add support to EXTRA_DISTRO_FEATURES
2013-07-29 22:57 ` [OE-core] " Rogerio Nunes
(?)
@ 2013-07-30 5:27 ` Abhijit Potnis
-1 siblings, 0 replies; 18+ messages in thread
From: Abhijit Potnis @ 2013-07-30 5:27 UTC (permalink / raw)
To: Rogerio Nunes
Cc: meta-freescale@yoctoproject.org, Rogerio Nunes, Otavio Salvador,
OpenEmbedded Core Mailing List
[-- Attachment #1: Type: text/plain, Size: 2078 bytes --]
Hello Otavio,
Thanks for pulling in the fix from meta-mentor. I am extremely sorry for
breaking so many builds, it was a gross mistake from my end and I did
overlook this issue. This fix should set right up the broken builds.
Regards,
Abhijit
On Mon, Jul 29, 2013 at 3:57 PM, Rogerio Nunes <ronunes@gmail.com> wrote:
> 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
> _______________________________________________
> meta-freescale mailing list
> meta-freescale@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-freescale
>
[-- Attachment #2: Type: text/html, Size: 3552 bytes --]
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] base.bbclass: Add support to EXTRA_DISTRO_FEATURES
2013-07-29 22:26 [PATCH] base.bbclass: Add support to EXTRA_DISTRO_FEATURES Otavio Salvador
2013-07-29 22:35 ` Otavio Salvador
@ 2013-07-30 10:59 ` Paul Eggleton
2013-07-30 12:00 ` Otavio Salvador
1 sibling, 1 reply; 18+ messages in thread
From: Paul Eggleton @ 2013-07-30 10:59 UTC (permalink / raw)
To: Otavio Salvador; +Cc: openembedded-core
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
--
Paul Eggleton
Intel Open Source Technology Centre
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] base.bbclass: Add support to EXTRA_DISTRO_FEATURES
2013-07-30 10:59 ` Paul Eggleton
@ 2013-07-30 12:00 ` Otavio Salvador
2013-07-30 12:14 ` Phil Blundell
0 siblings, 1 reply; 18+ messages in thread
From: Otavio Salvador @ 2013-07-30 12:00 UTC (permalink / raw)
To: Paul Eggleton; +Cc: Patches and discussions about the oe-core layer
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] base.bbclass: Add support to EXTRA_DISTRO_FEATURES
2013-07-30 12:00 ` Otavio Salvador
@ 2013-07-30 12:14 ` Phil Blundell
2013-07-30 12:24 ` Otavio Salvador
0 siblings, 1 reply; 18+ messages in thread
From: Phil Blundell @ 2013-07-30 12:14 UTC (permalink / raw)
To: Otavio Salvador
Cc: Paul Eggleton, Patches and discussions about the oe-core layer
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.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] base.bbclass: Add support to EXTRA_DISTRO_FEATURES
2013-07-30 12:14 ` Phil Blundell
@ 2013-07-30 12:24 ` Otavio Salvador
2013-07-30 14:46 ` Mark Hatle
0 siblings, 1 reply; 18+ messages in thread
From: Otavio Salvador @ 2013-07-30 12:24 UTC (permalink / raw)
To: Phil Blundell
Cc: Paul Eggleton, Patches and discussions about the oe-core layer
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] base.bbclass: Add support to EXTRA_DISTRO_FEATURES
2013-07-30 12:24 ` Otavio Salvador
@ 2013-07-30 14:46 ` Mark Hatle
2013-07-30 15:09 ` Paul Eggleton
2013-07-30 15:19 ` Phil Blundell
0 siblings, 2 replies; 18+ messages in thread
From: Mark Hatle @ 2013-07-30 14:46 UTC (permalink / raw)
To: openembedded-core
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
>
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] base.bbclass: Add support to EXTRA_DISTRO_FEATURES
2013-07-30 14:46 ` Mark Hatle
@ 2013-07-30 15:09 ` Paul Eggleton
2013-07-30 15:37 ` Mark Hatle
2013-07-30 15:19 ` Phil Blundell
1 sibling, 1 reply; 18+ messages in thread
From: Paul Eggleton @ 2013-07-30 15:09 UTC (permalink / raw)
To: Mark Hatle; +Cc: openembedded-core
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
--
Paul Eggleton
Intel Open Source Technology Centre
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] base.bbclass: Add support to EXTRA_DISTRO_FEATURES
2013-07-30 14:46 ` Mark Hatle
2013-07-30 15:09 ` Paul Eggleton
@ 2013-07-30 15:19 ` Phil Blundell
2013-07-30 15:43 ` Mark Hatle
1 sibling, 1 reply; 18+ messages in thread
From: Phil Blundell @ 2013-07-30 15:19 UTC (permalink / raw)
To: Mark Hatle; +Cc: openembedded-core
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.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] base.bbclass: Add support to EXTRA_DISTRO_FEATURES
2013-07-30 15:09 ` Paul Eggleton
@ 2013-07-30 15:37 ` Mark Hatle
0 siblings, 0 replies; 18+ messages in thread
From: Mark Hatle @ 2013-07-30 15:37 UTC (permalink / raw)
To: Paul Eggleton; +Cc: openembedded-core
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
>
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] base.bbclass: Add support to EXTRA_DISTRO_FEATURES
2013-07-30 15:19 ` Phil Blundell
@ 2013-07-30 15:43 ` Mark Hatle
2013-07-30 16:05 ` Phil Blundell
0 siblings, 1 reply; 18+ messages in thread
From: Mark Hatle @ 2013-07-30 15:43 UTC (permalink / raw)
To: Phil Blundell; +Cc: openembedded-core
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.
>
>
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] base.bbclass: Add support to EXTRA_DISTRO_FEATURES
2013-07-30 15:43 ` Mark Hatle
@ 2013-07-30 16:05 ` Phil Blundell
2013-07-30 21:00 ` Otavio Salvador
2013-07-30 21:01 ` Otavio Salvador
0 siblings, 2 replies; 18+ messages in thread
From: Phil Blundell @ 2013-07-30 16:05 UTC (permalink / raw)
To: Mark Hatle; +Cc: openembedded-core
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.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] base.bbclass: Add support to EXTRA_DISTRO_FEATURES
2013-07-30 16:05 ` Phil Blundell
@ 2013-07-30 21:00 ` Otavio Salvador
2013-07-30 21:01 ` Otavio Salvador
1 sibling, 0 replies; 18+ messages in thread
From: Otavio Salvador @ 2013-07-30 21:00 UTC (permalink / raw)
To: Phil Blundell; +Cc: Patches and discussions about the oe-core layer
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] base.bbclass: Add support to EXTRA_DISTRO_FEATURES
2013-07-30 16:05 ` Phil Blundell
2013-07-30 21:00 ` Otavio Salvador
@ 2013-07-30 21:01 ` Otavio Salvador
1 sibling, 0 replies; 18+ messages in thread
From: Otavio Salvador @ 2013-07-30 21:01 UTC (permalink / raw)
To: Phil Blundell; +Cc: Patches and discussions about the oe-core layer
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
^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2013-07-30 21:01 UTC | newest]
Thread overview: 18+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-07-29 22:26 [PATCH] base.bbclass: Add support to EXTRA_DISTRO_FEATURES Otavio Salvador
2013-07-29 22:35 ` Otavio Salvador
2013-07-29 22:35 ` Otavio Salvador
2013-07-29 22:57 ` Rogerio Nunes
2013-07-29 22:57 ` [OE-core] " Rogerio Nunes
2013-07-30 5:27 ` Abhijit Potnis
2013-07-30 10:59 ` Paul Eggleton
2013-07-30 12:00 ` Otavio Salvador
2013-07-30 12:14 ` Phil Blundell
2013-07-30 12:24 ` Otavio Salvador
2013-07-30 14:46 ` Mark Hatle
2013-07-30 15:09 ` Paul Eggleton
2013-07-30 15:37 ` Mark Hatle
2013-07-30 15:19 ` Phil Blundell
2013-07-30 15:43 ` Mark Hatle
2013-07-30 16:05 ` Phil Blundell
2013-07-30 21:00 ` Otavio Salvador
2013-07-30 21:01 ` Otavio Salvador
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.