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

[Andre McCurdy]

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

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
> Openembedded-devel at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel