On 9/7/17 3:57 AM, Andreas Müller wrote: > On Wed, Sep 6, 2017 at 9:23 PM, Mark Hatle <[email protected]> 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 > -- _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-devel
