Re: [OE-core][PATCH] perl: add integer module required for kernel >= 5.14

["Andrey Zhizhikin" <andrey.z@gmail.com>]

On Tue, Aug 31, 2021 at 3:41 PM Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
>
> On Tue, 2021-08-31 at 15:26 +0200, Andrey Zhizhikin wrote:
> > Richard,
> >
> > On Tue, Aug 31, 2021 at 2:29 PM Andrey Zhizhikin via
> > lists.openembedded.org <andrey.z=gmail.com@lists.openembedded.org>
> > wrote:
> > >
> > > On Tue, Aug 31, 2021 at 2:19 PM Richard Purdie
> > > <richard.purdie@linuxfoundation.org> wrote:
> > > >
> > > > On Tue, 2021-08-31 at 13:54 +0200, Andrey Zhizhikin wrote:
> > > > > Hello Richard,
> > > > >
> > > > > On Tue, Aug 31, 2021 at 12:03 PM Richard Purdie
> > > > > <richard.purdie@linuxfoundation.org> wrote:
> > > > > >
> > > > > > On Tue, 2021-08-31 at 11:53 +0200, Andrey Zhizhikin wrote:
> > > > > > > Hello Bruce,
> > > > > > >
> > > > > > > On Mon, Aug 30, 2021 at 11:12 PM Bruce Ashfield
> > > > > > > <bruce.ashfield@gmail.com> wrote:
> > > > > > > >
> > > > > > > > On Mon, Aug 30, 2021 at 4:55 PM Andrey Zhizhikin <andrey.z@gmail.com> wrote:
> > > > > > > > >
> > > > > > > > > Hello Richard,
> > > > > > > > >
> > > > > > > > > On Mon, Aug 30, 2021 at 10:30 PM Richard Purdie
> > > > > > > > > <richard.purdie@linuxfoundation.org> wrote:
> > > > > > > > > >
> > > > > > > > > > On Mon, 2021-08-30 at 20:05 +0000, Andrey Zhizhikin wrote:
> > > > > > > > > > > Kernel commit 12dd461ebd19 ("crypto: arm64 - generate *.S by Perl at
> > > > > > > > > > > build time instead of shipping them") uses perl to generate assembler
> > > > > > > > > > > files for crypto functionality, which relies on the integer.pm module to
> > > > > > > > > > > be provided.
> > > > > > > > > > >
> > > > > > > > > > > Add this module to FILES and export it for build system.
> > > > > > > > > > >
> > > > > > > > > > > Signed-off-by: Andrey Zhizhikin <andrey.z@gmail.com>
> > > > > > > > > > > Cc: Bruce Ashfield <bruce.ashfield@gmail.com>
> > > > > > > > > > > Cc: Alexander Kanavin <alex.kanavin@gmail.com>
> > > > > > > > > > > ---
> > > > > > > > > > >  meta/recipes-devtools/perl/perl_5.34.0.bb | 1 +
> > > > > > > > > > >  1 file changed, 1 insertion(+)
> > > > > > > > > > >
> > > > > > > > > > > diff --git a/meta/recipes-devtools/perl/perl_5.34.0.bb b/meta/recipes-devtools/perl/perl_5.34.0.bb
> > > > > > > > > > > index ab19a8d0be0..7a07b3f4911 100644
> > > > > > > > > > > --- a/meta/recipes-devtools/perl/perl_5.34.0.bb
> > > > > > > > > > > +++ b/meta/recipes-devtools/perl/perl_5.34.0.bb
> > > > > > > > > > > @@ -248,6 +248,7 @@ FILES:${PN} = "${bindir}/perl ${bindir}/perl.real ${bindir}/perl${PV} ${libdir}/
> > > > > > > > > > >                 ${libdir}/perl5/${PV}/strict.pm \
> > > > > > > > > > >                 ${libdir}/perl5/${PV}/warnings.pm \
> > > > > > > > > > >                 ${libdir}/perl5/${PV}/warnings \
> > > > > > > > > > > +               ${libdir}/perl5/${PV}/integer.pm \
> > > > > > > > > > >                 ${libdir}/perl5/${PV}/vars.pm \
> > > > > > > > > > >                 ${libdir}/perl5/site_perl \
> > > > > > > > > > >                 ${libdir}/perl5/${PV}/ExtUtils/MANIFEST.SKIP \
> > > > > > > > > >
> > > > > > > > > > Doesn't that mean something is missing an RDEPENDS on perl-module-integer rather
> > > > > > > > > > than adding to the main perl package?
> > > > > > > > >
> > > > > > > > > Good point! Now that I look at it - this does look a bit too intrusive
> > > > > > > > > (even though it did serve the purpose).
> > > > > > > > >
> > > > > > > > > I'm just not sure if I can craft it to RDEPENDS in kernel class instead...
> > > > > > > > >
> > > > > > > > > This is definitely required by newer kernel builds (>= 5.14), but I'm
> > > > > > > > > no expert in how those dependencies are set in kernel class. Would
> > > > > > > > > need to look a bit deeper there.
> > > > > > > >
> > > > > > > > Doing it consistently is the challenge, so we tend to not set them in
> > > > > > > > the classes themselves.
> > > > > > >
> > > > > > > Understood. Now I see the reason why I didn't observe any of those
> > > > > > > dependencies in the kernel classes themselves.
> > > > > > >
> > > > > > > >
> > > > > > > > You have to check both the architecture and the version for many of
> > > > > > > > the depends/rdepends.
> > > > > > > >
> > > > > > > > Which is why I tend to carry dependencies like this in the individual
> > > > > > > > recipes, since the version is known and the arch is an easy check.
> > > > > > >
> > > > > > > This is not a problem for me, as I can add it to the layer kernel
> > > > > > > recipe. What I believe the problem might be is that after kernel
> > > > > > > migration, eventually all BSP layers would have the same RDEPENDS
> > > > > > > defined in their respective kernel recipes. This does call for some
> > > > > > > unification imho, but I'm not sure how this can be properly done.
> > > > > > >
> > > > > > > The other thing here is: the same Perl module would be required in the
> > > > > > > SDK in order to build Kernels >= 5.14 standalone.
> > > > > > > I was planning to include it into RDEPENDS of
> > > > > > > nativesdk-packagegroup-sdk-host, but contemplating now if this is a
> > > > > > > proper way of doing it. I see that the package group contains flex and
> > > > > > > bison for kernel builds, so adding perl integer module there seems
> > > > > > > quite logical to me. Unless there are good reasons not to do it this
> > > > > > > way.
> > > > > >
> > > > > > Isn't the kernel-devsrc recipe the place this should be added? You'd need that
> > > > > > to be building the kernel on target?
> > > > >
> > > > > This is needed to build kernel on the host using standalone SDK.
> > > > >
> > > > > To my knowledge, Perl (as a base package) is already provided in the
> > > > > SDK, but required module is not. This makes the tooling incomplete and
> > > > > breaks the build when kernel is upgraded to latest versions.
> > > > >
> > > > > I've just tried it, and adding it to kernel-devsrc did not solve the
> > > > > missing module issue.
> > > >
> > > > As far as I recall we don't include perl in our SDKs and rely on the one from
> > > > the host. Which SDK exactly are you using?
> > >
> > > This is then rather strange and confusing...
> > >
> > > I do generate standalone SDK via 'bitbake meta-toolchain', which to my
> > > current understanding should pull only minimal set of toolchain
> > > component into its content. This does include Perl, perhaps through
> > > some dependency resolution.
> > >
> > > Since I use distro from meta-freescale layer - it might be (but less
> > > likely) coming from some dependencies inside of it... I can try to
> > > generate it off Poky distro now to see if it has Perl inside as well.
> >
> > Just to follow-up on this: nativesdk-perl and a bunch of modules are
> > pulled into the SDK by autoconf, which lists them in it's RDEPENDS.
> >
> > This behavior is distro-agnostic, and making Perl to be installed into
> > SDK in any case.
>
> I had a further look and I think I'm confusing nativesdk-buildtools-perl-dummy
> which is included in buildtool-tarball and nativesdk-sdk-provides-dummy which is
> included in wider SDKs. The latter excludes things like bash and env but not
> perl.

Thanks for tracing it out! I had the same conclusion when I looked at
those package groups and runtime dependencies.

I guess if nativesdk-sdk-provides-dummy would exclude Perl, this might
lead to confusing autoconf and eventually break things, at least my
common sense is telling me so. Therefore, it is OK not to exclude it
via nativesdk-sdk-provides-dummy.

>Just to help confuse things, target-sdk-provides-dummy does exclude perl.
>
> I guess that brings us back to nativesdk-packagegroup-sdk-host as the place
> these things are listed (and where autoconf comes from).

OK, then I would send another patch to have the module included there.
This does sound logical to me, and at least in this case it would be a
bit more transparent why Perl is included in the SDK (in contrary to
the obscured dependency of autoconf).

>
> Cheers,
>
> Richard
>
>
>


-- 
Regards,
Andrey.