About GPLv2's native recipe
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.
Signature · 3 lines
Thanks Robert
Quoted 6 lines · Robert Yang
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.
Signature · 3 lines
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
Quoted 10 lines · Otavio Salvador
Quoted 6 lines · Robert Yang
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.
Signature · 5 lines
Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics
Quoted 16 lines · Christopher Larson
Quoted 11 lines · Otavio Salvador
Quoted 6 lines · Robert Yang
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.
Quoted 7 lines
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.
Signature · 3 lines
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
Quoted 10 lines · Otavio Salvador
Quoted 6 lines · Robert Yang
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
Quoted 2 lines · On Friday 23 January 2015 09:04:28 akuster808 wrote:
Quoted 1 line · Otavio Salvador
On Fri, Jan 23, 2015 at 12:12 AM, Robert Yang <[email protected]>
Quoted 11 lines · wrote:
Quoted 8 lines
Quoted 6 lines
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
Signature · 2 lines
Paul Eggleton Intel Open Source Technology Centre
Hi Robert,
Quoted 7 lines · Robert Yang
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-imagesINCOMPATIBLE_LICENSE = "GPL-3.0 LGPL-3.0 AGPL-3.0"
Best regards,
Eric
Quoted 9 lines · Eric Bénard
Quoted 7 lines · Robert Yang
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.
Quoted 7 lines
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.
Signature · 5 lines
Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics
Quoted 22 lines · Christopher Larson
On Sun, Jan 25, 2015 at 2:18 PM, Eric Bénard <[email protected] <mailto:[email protected]>> wrote:
Le Fri, 23 Jan 2015 10:12:16 +0800, Robert Yang <[email protected] <mailto:[email protected]>> 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"
Quoted 2 lines
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
Quoted 6 lines
--
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics