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

[Andre McCurdy]

On Tue, Sep 1, 2015 at 3:07 PM, Martin Jansa <martin.jansa at gmail.com> wrote:
> 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 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.
>
> 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.

Yes. If a recipe gets merged into oe-core and updated and the meta-oe
removal patch is slow to be sent out then, due to the layer priority,
it's the meta-oe users who suffer. That transition phase uncertainty
would go away if meta-oe were a lower priority than oe-core.

>> 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.

I found this. Is that the one you mean?

  https://bugzilla.yoctoproject.org/show_bug.cgi?id=5546

Anyway, I don't use X11 and I don't know the history here so I'm
probably over-simplifying. My comment was only based on the fact that
xserver-nodm-init is a ~70 line script and the x11-common -vs-
xserver-common differences could be handled via a conditional test in
the script. Not ideal but perhaps better than maintaining two
independent forks of xserver-nodm-init.


> --
> Martin 'JaMa' Jansa     jabber: Martin.Jansa at gmail.com
>
> --
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
>