Bug 13946

The perl-module-x86-64-linux-* modules should never be created in the first place. I have a patch out for review which fixes that:

diff --git a/meta/recipes-devtools/perl/perl_5.30.2.bb b/meta/recipes-devtools/perl/perl_5.30.2.bb
index 26138ea9e5..804520d885 100644
--- a/meta/recipes-devtools/perl/perl_5.30.2.bb
+++ b/meta/recipes-devtools/perl/perl_5.30.2.bb
@@ -306,7 +306,7 @@ python split_perl_packages () {
     do_split_packages(d, libdir, r'Module/([^\/]*)\.pm', '${PN}-module-%s', 'perl module %s', recursive=True, allow_dirs=False, match_path=True, prepend=False)
     do_split_packages(d, libdir, r'Module/([^\/]*)/.*', '${PN}-module-%s', 'perl module %s', recursive=True, allow_dirs=False, match_path=True, prepend=False)
     do_split_packages(d, libdir, r'.*linux/([^\/].*)\.(pm|pl|e2x)', '${PN}-module-%s', 'perl module %s', recursive=True, allow_dirs=False, match_path=True, prepend=False)
-    do_split_packages(d, libdir, r'(^(?!(CPAN\/|CPANPLUS\/|Module\/|unicore\/)[^\/]).*)\.(pm|pl|e2x)', '${PN}-module-%s', 'perl module %s', recursive=True, allow_dirs=False, match_path=True, prepend=False)
+    do_split_packages(d, libdir, r'(^(?!(CPAN\/|CPANPLUS\/|Module\/|unicore\/|.*linux\/)[^\/]).*)\.(pm|pl|e2x)', '${PN}-module-%s', 'perl module %s', recursive=True, allow_dirs=False, match_path=True, prepend=False)
 
     # perl-modules should recommend every perl module, and only the
     # modules. Don't attempt to use the result of do_split_packages() as some


however, this does not explain why the storable module is present in some builds and not others. The only way that can be explained is if

/usr/lib64/perl5/5.30.2/Storable.pm

somehow sometimes is installed as:

/usr/lib64/perl5/5.30.2/x86_64-linux/Storable.pm

but I cannot see how that is happening at a look through the perl build system. It could be some kind of host system "contamination" but I can't see what/where.

It's probably worth adding a check in the recipe to specifically look for cases where this file gets created and fail the build instead of producing bad sstate

Did a build of perl on my arm64 box for an arm64 target:

perl-module-storable:
        /usr/lib/perl5/5.32.0/aarch64-linux/Storable.pm

Is the cause that sometimes there is a companion .so and sometimes not?

For me:

perl-module-storable:
        /usr/lib/perl5/5.32.0/aarch64-linux/Storable.pm
        /usr/lib/perl5/5.32.0/aarch64-linux/auto/Storable/Storable.so

So the aarch64-linux bit is appropriate if there's also a .so.

I think I may have the comment backwards and I meant:

"""
/usr/lib64/perl5/5.30.2/x86_64-linux/Storable.pm

somehow sometimes is installed as:

/usr/lib64/perl5/5.30.2/Storable.pm
"""

since my local build has "/5.30.2/x86_64-linux/Storable.pm" as does everyone elses.

The test we should perhaps add is to detect if /usr/lib64/perl5/5.30.2/Storable.pm ever is installed and error if so as that is the build we need to find if it happens.

Has this happened recently?

If it did, it would no longer show up due to my other fix. This is why I'd like to add the sanity test before we close this.

https://lists.openembedded.org/g/openembedded-core/message/141421 should add a check for the invalid state at do_install()

The patch will prevent this issue from occurring silently, so we can close this. If the issue occurs again, a new bug should be opened.

I added Joshua's patch to my dunfell test builds and got this error twice: on oe-selftest-centos and oe-selftest-fedora.  Both oe-selftest-ubuntu and oe-selftest-debian were successful.

https://autobuilder.yoctoproject.org/typhoon/#/builders/79/builds/1245

https://autobuilder.yoctoproject.org/typhoon/#/builders/86/builds/1229

I'll open a new bug too