[RFC] About GPLv2's native recipe

[RFC] About GPLv2's native recipe

[Robert Yang]

Hello,

We have several GPLv2 recipes such as m4-native_1.4.9.bb, while we also
have GPLv3's m4-native_1.4.17.bb, I think that we can remove
m4-native_1.4.9.bb if the target m4_1.4.9.bb builds well ?

I'd like to remove it because we don't build the lower native version by
default, and we don't know whether it works or when it would fail.

-- 
Thanks

Robert

Re: [RFC] About GPLv2's native recipe

[Otavio Salvador]

On Fri, Jan 23, 2015 at 12:12 AM, Robert Yang <liezhi.yang@windriver.com> wrote:
> We have several GPLv2 recipes such as m4-native_1.4.9.bb, while we also
> have GPLv3's m4-native_1.4.17.bb, I think that we can remove
> m4-native_1.4.9.bb if the target m4_1.4.9.bb builds well ?
>
> I'd like to remove it because we don't build the lower native version by
> default, and we don't know whether it works or when it would fail.

I second this; not tested recipes are always good to remove.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: [RFC] About GPLv2's native recipe

[Christopher Larson]

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

On Fri, Jan 23, 2015 at 5:47 AM, Otavio Salvador <otavio@ossystems.com.br>
wrote:

> On Fri, Jan 23, 2015 at 12:12 AM, Robert Yang <liezhi.yang@windriver.com>
> wrote:
> > We have several GPLv2 recipes such as m4-native_1.4.9.bb, while we also
> > have GPLv3's m4-native_1.4.17.bb, I think that we can remove
> > m4-native_1.4.9.bb if the target m4_1.4.9.bb builds well ?
> >
> > I'd like to remove it because we don't build the lower native version by
> > default, and we don't know whether it works or when it would fail.
>
> I second this; not tested recipes are always good to remove.


The one case I'd be concerned with is where a native tool is used to
crosscompile something for the target, specifically in the case of
scripting tools which often have implicit dependency on the exact same
version, so it can parse what it needs to parse to build. Python for
example, I doubt you'd want to try to use 2.4 as part of the 2.7
crosscompilation process. m4 being a scripting language, that might be the
case here. Of course, if the language is compatible between the two
versions, maybe that's a non-issue.
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics

[-- Attachment #2: Type: text/html, Size: 2027 bytes --]

Re: [RFC] About GPLv2's native recipe

[Otavio Salvador]

On Fri, Jan 23, 2015 at 2:24 PM, Christopher Larson <clarson@kergoth.com> wrote:
>
> On Fri, Jan 23, 2015 at 5:47 AM, Otavio Salvador <otavio@ossystems.com.br>
> wrote:
>>
>> On Fri, Jan 23, 2015 at 12:12 AM, Robert Yang <liezhi.yang@windriver.com>
>> wrote:
>> > We have several GPLv2 recipes such as m4-native_1.4.9.bb, while we also
>> > have GPLv3's m4-native_1.4.17.bb, I think that we can remove
>> > m4-native_1.4.9.bb if the target m4_1.4.9.bb builds well ?
>> >
>> > I'd like to remove it because we don't build the lower native version by
>> > default, and we don't know whether it works or when it would fail.
>>
>> I second this; not tested recipes are always good to remove.
>
>
> The one case I'd be concerned with is where a native tool is used to
> crosscompile something for the target, specifically in the case of scripting
> tools which often have implicit dependency on the exact same version, so it
> can parse what it needs to parse to build. Python for example, I doubt you'd
> want to try to use 2.4 as part of the 2.7 crosscompilation process. m4 being
> a scripting language, that might be the case here. Of course, if the
> language is compatible between the two versions, maybe that's a non-issue.

In this specific case, being m4 changed only minor versions it should
be backward compatible.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: [RFC] About GPLv2's native recipe

[akuster808]

On 01/23/2015 04:47 AM, Otavio Salvador wrote:
> On Fri, Jan 23, 2015 at 12:12 AM, Robert Yang <liezhi.yang@windriver.com> wrote:
>> We have several GPLv2 recipes such as m4-native_1.4.9.bb, while we also
>> have GPLv3's m4-native_1.4.17.bb, I think that we can remove
>> m4-native_1.4.9.bb if the target m4_1.4.9.bb builds well ?
>>
>> I'd like to remove it because we don't build the lower native version by
>> default, and we don't know whether it works or when it would fail.
>
> I second this; not tested recipes are always good to remove.
>

Speaking of not tested, what about 'BLACKLISTED' recipes? is there a 
policy regarding how long to keep them around when they are in that state?

- Armin

Re: [RFC] About GPLv2's native recipe

[Paul Eggleton]

On Friday 23 January 2015 09:04:28 akuster808 wrote:
> On 01/23/2015 04:47 AM, Otavio Salvador wrote:
> > On Fri, Jan 23, 2015 at 12:12 AM, Robert Yang <liezhi.yang@windriver.com> 
wrote:
> >> We have several GPLv2 recipes such as m4-native_1.4.9.bb, while we also
> >> have GPLv3's m4-native_1.4.17.bb, I think that we can remove
> >> m4-native_1.4.9.bb if the target m4_1.4.9.bb builds well ?
> >> 
> >> I'd like to remove it because we don't build the lower native version by
> >> default, and we don't know whether it works or when it would fail.
> > 
> > I second this; not tested recipes are always good to remove.
> 
> Speaking of not tested, what about 'BLACKLISTED' recipes? is there a
> policy regarding how long to keep them around when they are in that state?

We don't blacklist recipes in OE-Core, so you'd have to address that question 
to Martin or other layer maintainers who do do that.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: [RFC] About GPLv2's native recipe

[Eric Bénard]

Hi Robert,

Le Fri, 23 Jan 2015 10:12:16 +0800,
Robert Yang <liezhi.yang@windriver.com> a écrit :
> We have several GPLv2 recipes such as m4-native_1.4.9.bb, while we also
> have GPLv3's m4-native_1.4.17.bb, I think that we can remove
> m4-native_1.4.9.bb if the target m4_1.4.9.bb builds well ?
> 
> I'd like to remove it because we don't build the lower native version by
> default, and we don't know whether it works or when it would fail.
> 
if you want to build a system without GPLv3 ("supported for only
minimal and base images" as stated in the manual) you may need GPLv2
tools :
http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#ref-images
INCOMPATIBLE_LICENSE = "GPL-3.0 LGPL-3.0 AGPL-3.0"

Best regards,
Eric

Re: [RFC] About GPLv2's native recipe

[Christopher Larson]

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

On Sun, Jan 25, 2015 at 2:18 PM, Eric Bénard <eric@eukrea.com> wrote:

> Le Fri, 23 Jan 2015 10:12:16 +0800,
> Robert Yang <liezhi.yang@windriver.com> a écrit :
> > We have several GPLv2 recipes such as m4-native_1.4.9.bb, while we also
> > have GPLv3's m4-native_1.4.17.bb, I think that we can remove
> > m4-native_1.4.9.bb if the target m4_1.4.9.bb builds well ?
> >
> > I'd like to remove it because we don't build the lower native version by
> > default, and we don't know whether it works or when it would fail.
> >
> if you want to build a system without GPLv3 ("supported for only
> minimal and base images" as stated in the manual) you may need GPLv2
> tools :
>
> http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#ref-images
> INCOMPATIBLE_LICENSE = "GPL-3.0 LGPL-3.0 AGPL-3.0"
>

GPLv3 native tools will still be used in such a build, as far as I know,
just not the target ones.
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics

[-- Attachment #2: Type: text/html, Size: 2007 bytes --]

Re: [RFC] About GPLv2's native recipe

[Robert Yang]

On 01/26/2015 06:39 AM, Christopher Larson wrote:
>
> On Sun, Jan 25, 2015 at 2:18 PM, Eric Bénard <eric@eukrea.com
> <mailto:eric@eukrea.com>> wrote:
>
>     Le Fri, 23 Jan 2015 10:12:16 +0800,
>     Robert Yang <liezhi.yang@windriver.com <mailto:liezhi.yang@windriver.com>> a
>     écrit :
>     > We have several GPLv2 recipes such asm4-native_1.4.9.bb <http://m4-native_1.4.9.bb>, while we also
>     > have GPLv3'sm4-native_1.4.17.bb <http://m4-native_1.4.17.bb>, I think that we can remove
>     >m4-native_1.4.9.bb <http://m4-native_1.4.9.bb> if the target m4_1.4.9.bb
>     <http://m4_1.4.9.bb> builds well ?
>     >
>     > I'd like to remove it because we don't build the lower native version by
>     > default, and we don't know whether it works or when it would fail.
>     >
>     if you want to build a system without GPLv3 ("supported for only
>     minimal and base images" as stated in the manual) you may need GPLv2
>     tools :
>     http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#ref-images
>     INCOMPATIBLE_LICENSE = "GPL-3.0 LGPL-3.0 AGPL-3.0"
>
>
> GPLv3 native tools will still be used in such a build, as far as I know, just
> not the target ones.

Yes, you're right.

Thanks for the reply everyone, I will address your concerns, try to
remove some recipes and send patches out.

// Robert


> --
> Christopher Larson
> clarson at kergoth dot com
> Founder - BitBake, OpenEmbedded, OpenZaurus
> Maintainer - Tslib
> Senior Software Engineer, Mentor Graphics