Re: [meta-oe][PATCH] parted_1.8.6.bb: add parted that not GPLv3

[Martin Jansa <martin.jansa@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 4689 bytes --]

On Tue, Sep 01, 2015 at 02:57:29PM -0700, Andre McCurdy wrote:
> On Mon, Aug 31, 2015 at 11:36 PM, Anders Darander <anders@chargestorm.se> wrote:
> > * Andre McCurdy <armccurdy@gmail.com> [150831 22:03]:
> >
> >> On Mon, Aug 31, 2015 at 12:38 PM, Andreas Müller
> >> <schnitzeltony@googlemail.com> wrote:
> >> > On Mon, Aug 31, 2015 at 9:11 PM, Andre McCurdy <armccurdy@gmail.com> wrote:
> >> >> On Mon, Aug 31, 2015 at 10:58 AM, Martin Jansa <martin.jansa@gmail.com> 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: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 188 bytes --]