On Tue, Sep 01, 2015 at 02:57:29PM -0700, Andre McCurdy wrote: > 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.
Yes, that's why I'm asking people migrating recipes to oe-core to send removal patch to meta-oe (while verifying that what they migrated wasn't modified in meta-oe after they created their copy) - some people do it some don't. > 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. Not minor changes, there is long ticket in bugzilla mostly related to x11-common xserver-common, which result in this xserver-nodm-init difference. Regards, -- Martin 'JaMa' Jansa jabber: [email protected]
signature.asc
Description: Digital signature
-- _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-devel
