On Mon, Aug 31, 2015 at 11:36 PM, Anders Darander <[email protected]> wrote: > * Andre McCurdy <[email protected]> [150831 22:03]: > >> On Mon, Aug 31, 2015 at 12:38 PM, Andreas Müller >> <[email protected]> wrote: >> > On Mon, Aug 31, 2015 at 9:11 PM, Andre McCurdy <[email protected]> wrote: >> >> On Mon, Aug 31, 2015 at 10:58 AM, Martin Jansa <[email protected]> >> >> wrote: >> >>> I cannot take this to meta-oe, because as soon as it's added there it >> >>> will be used by all DISTROs even those who don't mind having GPLv3 >> >>> version. > >> >>> Everybody would need to define PREFERRED_VERSION, because >> >>> DEFAULT_PREFERENCE is useless across different layers :/ >> >>> https://bugzilla.yoctoproject.org/show_bug.cgi?id=2964 > >> >>> So this either has to be introduced in oe-core or in completely separate >> >>> layer which would be included only by those who cannot use GPLv3. > > I think that the correct way to handle those recipes (that isn't core > enough to be kept in oe-core) is to create a new layer, maybe meta-gplv2 > or meta-nongplv3; dependig on how explicit the naming should be. This > layer could very well be put in meta-openembedded (the meta layer, not > meta-oe). > >> >> Third option would be to reduce the priority of meta-oe to be lower >> >> than oe-core. > >> >> That seems logical regardless of any GPLv3 discussion - since meta-oe >> >> "fills in the gaps" in oe-core, if something _is_ present in oe-core >> >> then it probably should be the default version. > >> > This scares me: to get a recipe in with old version not supporting >> > modern file systems you want to change meta-oe's layer priority >> > risiking unknown issues. I wonder how far the GPLv3 avoidance hype >> > takes us... > >> No, if you read the various threads, my preference is to have the >> GPLv2 parted recipe in oe-core. That option has been shot down though >> and the general consensus seems to be that the older version of parted >> is too buggy to be included anywhere in OE. That topic seems to be >> closed. > >> Trying to understand why meta-oe needs a higher priority than oe-core >> is a separate topic. If the priorities were changed it would allow >> older (and newer) versions of oe-core recipes to safely live in >> meta-oe. That would help non-GPLv3 versions of GPLv3 packages, but it >> might be useful in other cases too. > > Well, changing the priority might have effects on peoples current > builds; most likely effects that you don't anticipate during an upgrade. > > And at least periodically, meta-oe has modified how recipes from oe-core > has been built. Thus, the need for a higher priority of meta-oe as > compared to oe-core. (I know that I've had to undo such changes in my > own layers in older releases).
Maybe just a personal preference, but I think completely replacing a recipe is a hackish approach best reserved for private layers. Giving meta-oe a higher priority wouldn't be needed if the oe-core recipes were modified via a .bbappend or by getting the meta-oe tweaks merged into oe-core. I don't know the history though. Maybe there are reasons why this hasn't been possible. According to bitbake-layers, the current list of oe-core recipes which are over-ridden by meta-oe is quite short though: iso-codes: meta-oe 1.4 meta 3.58 libcap-ng: meta-oe 0.7.7 meta 0.7.7 nativesdk-swig: meta-oe 3.0.6 meta 3.0.6 xserver-nodm-init: meta-oe 2.0 meta 1.0 The first 3 are transient (the oe-core versions were recently added and the meta-oe versions can be removed). Having meta-oe over-ride oe-core isn't necessary or helpful for these recipes. I'm not sure what's going on with xserver-nodm-init. Both versions are being updated independently but it looks like they could be unified with minor changes. > Cheers, > Anders > > -- > Anders Darander > ChargeStorm AB / eStorm AB > -- > _______________________________________________ > Openembedded-devel mailing list > [email protected] > http://lists.openembedded.org/mailman/listinfo/openembedded-devel -- _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-devel
