[OE-core] [PATCH] base.bbclass: Add support to EXTRA_DISTRO_FEATURES

[Mark Hatle]

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
>