[oe] [PATCH 22/31] vim: Remove xfce vim bbappend

[Mark Hatle]

On 9/7/17 3:57 AM, Andreas Müller wrote:
> On Wed, Sep 6, 2017 at 9:23 PM, Mark Hatle <mark.hatle at windriver.com> wrote:
>> Changing the behavior of a recipe by including a layer is not allowed
>> by the yocto-compat-layer script.
> I have a question on this: What is the yocto target for this matter?
> Will there be times that a layer cannot change recipe's behavior
> anymore? Background: Personally I don't care much (yet) for
> yocto-compat-layer script - am busy enough to keep my images building
> and running with the functionality I am interested in. But if this
> will be forbidden by design in the future I have to expect further
> activities. Not to be misunderstood: I understand why this is part of
> requirements and only want to know what I need to put on my personal
> TODO.

My understanding of the YP requirement here is simple:

Inclusion of a layer should not change behavior of existing components from
other layers, without the user doing something to activate the change in
functionality.

Typically this would be done through a distribution configuration, i.e.
PACKAGECONFIG, DISTRO_FEATURES, MACHINE_FEATURES, etc.

So just setting a value, which ends up changing package behaviors as part of the
inclusion of a layer fails the test.


So in this specific case, if I include meta-xfce (even if I have no intention of
using xfce), the behavior of 'vim' will change without any way for me to control it.

Adding a PACKAGECONFIG, or some other 'switch' that only enables the change when
I've enabled it would resolve this.  But in the case of VIM, I really have no
idea what the expected behavior is here.  I do believe it should be improved in
'some way' rather then removal.   Either by changing the system default (i.e.
directly in meta-openembedded/meta-oe/recipes-support/vim) or by adding a
PACKAGECONFIG that changes behavior, etc.


This is similar to the meta-gnome issue.. Why did I create a config file, to
address exactly the same issue.  Is a random configuration file that nobody is
going to just 'find' a good idea?  No.. it's horrible.  but it was the only way
I could see to deal with this requirement.

--Mark

> Andreas
>