[yocto] [RFC][meta-gplv2] layer priority and worth creating branch compatible with morty?

[Martin Jansa]

You're right, after fixing our tooling to correctly override
BBFILE_PRIORITY based on priorities in layer list I'm seeing such
issue.e.g. gstreamer failing with:

| autopoint: *** The AM_GNU_GETTEXT_VERSION declaration in your configure.ac
              file requires the infrastructure from gettext-0.17 but this
version               is older. Please upgrade to gettext-0.17 or newer.
| autopoint: *** Stop.
|
| autopoint failed
| WARNING: exit code 1 from a shell command.

and similar issues in apt, grub, netcf, rrdtool.

There is quite a few native BBCLASSEXTENDs in meta-gplv2:
OE @ ~/meta-gplv2 $ git grep BBCLASSEXTEND
recipes-core/gettext/gettext_0.16.1.bb:BBCLASSEXTEND = "native nativesdk"
recipes-core/readline/readline_5.2.bb:BBCLASSEXTEND = "native nativesdk"
recipes-devtools/elfutils/elfutils_0.148.bb:BBCLASSEXTEND = "native
nativesdk"
recipes-devtools/m4/m4_1.4.9.bb:BBCLASSEXTEND = "nativesdk"
recipes-devtools/mtools/mtools_3.9.9.bb:BBCLASSEXTEND = "native nativesdk"
recipes-extended/cpio/cpio_v2.inc:BBCLASSEXTEND = "native"
recipes-extended/findutils/findutils.inc:BBCLASSEXTEND = "native nativesdk"
recipes-extended/gperf/gperf.inc:BBCLASSEXTEND = "native"
recipes-extended/libidn/libidn_0.6.14.bb:BBCLASSEXTEND = "native nativesdk"
recipes-extended/tar/tar.inc:BBCLASSEXTEND = "native nativesdk"
recipes-extended/texinfo/texinfo_4.8.bb:BBCLASSEXTEND = "native"
recipes-support/gdbm/gdbm_1.8.3.bb:BBCLASSEXTEND = "native nativesdk"
recipes-support/nettle/nettle.inc:BBCLASSEXTEND = "native nativesdk"





On Fri, Apr 21, 2017 at 11:19 PM, Andre McCurdy <armccurdy at gmail.com> wrote:

> On Fri, Apr 21, 2017 at 1:59 PM, Martin Jansa <martin.jansa at gmail.com>
> wrote:
> > 1) layer priority, currently it has:
> >        BBFILE_PRIORITY_gplv2 = "1"
> >    which is lower than oe-core with:
> >        BBFILE_PRIORITY_core = "5"
> >    so in order to use recipes from meta-gplv2 layer, user has to add
> >    couple PREFERRED_VERSIONS. Was this intended use for meta-gplv2?
>
> I guess the intention is that if you blacklist GPLv3 etc then only the
> recipes in meta-gplv2 will be considered.
>
> >    I can see some advantages of this (that the layer can be included
> >    without immediate side effects), but on the other hand why would
> >    anyone include this layer if he isn't deeply scared from (L)GPLv3
> >    versions sneaking into the build?
> >    In our local builds I'm bumping the priority to 6 to resolve this.
>
> If any of the recipes in meta-gplv2 still contain BBCLASSEXTEND =
> "native" then that could cause problems (generally you only want to
> use the older recipes for the target, not for -native).
>
> >    Alternatively we can add some conf/distro/gplv2-versions.inc file
> >    in meta-gplv2 so that people who want to use all available recipes
> >    in gplv2 compatible version can include it in their DISTRO.
> >
> > 2) branch for morty, currently the recipes aren't compatible with morty
> >    but with e.g. gnutls version added there it might be better option
> >    to share the gplv2 work there even when oe-core/morty contains most
> >    of these recipes as well.
> >    The recipes I had to modify to be compatible with morty are:
> >    https://github.com/shr-project/meta-gplv2/commits/jansa/morty
> >    88d1052 coreutils: make it compatible with Yocto 2.2 Morty
> >    5e08ac2 rsync: make it compatible with Yocto 2.2 Morty
> >    b33037f libiconv: make it compatible with Yocto 2.2 Morty
> >
> > --
> > Martin 'JaMa' Jansa     jabber: Martin.Jansa at gmail.com
> >
> > --
> > _______________________________________________
> > yocto mailing list
> > yocto at yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20170424/d4d25a40/attachment.html>