Re: [PATCH] base.bbclass: Add support to EXTRA_DISTRO_FEATURES

[Mark Hatle <mark.hatle@windriver.com>]

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.
>
>