[OE-core] meta-gplv2? [Was Re: parted_1.8.6.bb: add parted that not GPLv3]

[Martin Jansa]

On Tue, Aug 18, 2015 at 11:11:11AM +0100, Richard Purdie wrote:
> On Tue, 2015-08-18 at 11:03 +0200, Martin Jansa wrote:
> > On Thu, Aug 13, 2015 at 10:42:54AM +0200, Philip Balister wrote:
> > > On 08/11/2015 10:46 PM, Otavio Salvador wrote:
> > > > On Tue, Aug 11, 2015 at 5:36 PM, Burton, Ross <ross.burton at intel.com> wrote:
> > > >>
> > > >> On 11 August 2015 at 16:46, Khem Raj <raj.khem at gmail.com> wrote:
> > > >>>
> > > >>> can we freeze this thread please.
> > > >>
> > > >>
> > > >> Or more usefully, reboot it.  Philip, you're turning into Koen!  Alex, if
> > > >> someone on this list asks what Poky is, 99% of the time they're trolling.
> > > >> :)
> > > >>
> > > >> The original and unanswered question was "should oe-core continue to
> > > >> maintain GPLv2 recipes where upstream has moved to GPLv3 or should those
> > > >> recipes move to a standalone layer" with various implied questions:
> > > >>
> > > >> - If the v2 recipes move to a separate layer, who own/maintains/tests it?
> > > >> - Should there be v2 recipes for every recipe that has moved to v3, or only
> > > >> (as is now) the "more-core" recipes (currently YP tests that core-image-base
> > > >> builds without GPLv3, nothing else more complicated)
> > > >> - Should meta-gplv2 only contain recipes from oe-core, or all layers?  If
> > > >> other layers decide to hold both v3 and v2 recipes (not that I'm aware any
> > > >> have), what makes oe-core special?
> > > >>
> > > >> I'm torn, Richard is torn.  Neither of those are useful to forming a
> > > >> decision.  Does anyone else have any *useful* feedback?
> > > > 
> > > > I think it is a matter of resource usage.
> > > > 
> > > > Up to now, the GPLv2 maintenance has not been so hard and thus I would
> > > > say for us to stay as is for now. We should revisit this for every
> > > > release and review if it is time for split it or not.
> > > > 
> > > 
> > > This would be a good time to remind us who the audience is for the gplv2
> > > recipes so we understand the amount of manpower behind their maintenance.
> > > 
> > > My concern keeping then in core is that the commnunity who uses them
> > > will reduce over time and they will bitrot. If that happens, we should
> > > create a layer for them and remove them from core.
> > 
> > It's still better to let them bitrot collectively in central layer than
> > every OE user with this requirement maintaining old GPLv2 recipes in own
> > layers and re-inventing the workarounds needed to build the rest of the
> > system with latest upstream layers.
> 
> I don't think anyone is suggesting we just abandon the idea and force
> everyone to do this individually. The question is more about whether it
> still makes sense to have the GPLv2 recipes in OE-Core or a separate
> layer. It does also raise questions of scope, there are GPLv2 recipes
> which OE-Core doesn't have and are not part of its stated policy (e.g.
> screen being the current example).
> 
> I do think its right to ask these questions although I'm still undecided
> about what the best solution is...

Is it still true that autobuilder cannot test different sets of layers
for different builds?

It would be nice to see meta-gplv2 as separate layer, but tested and
maintained as it is now inside oe-core (possibly with more help from
outside especially if we can move some other recipes there as well).
That way autobuilder can test meta-gplv2 layer only in non-GPLv3 builds
and people who don't mind having GPLv3 components don't need to see
"bit-rotten old versions" in proper oe-core.

I was suggesting the same for sato in OEDAM (core-image built without
meta-sato in one autobuilder job, then sato-image with meta-sato
included in separate job), but IIRC there were some autobuilder
limitations which prevented to use metadata layers like this (which
seems very sad).

Regards,

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20150818/490aff3b/attachment-0002.sig>