Add README to the release tarballs (named such that it doesn't clash with perl tarball itself, e.g. readme-perlcross.md))

[kanavin]

The rationale is that the tarballs do not contain any licensing information whatsoever otherwise, which complicates automated licensing checks and automated license manifest creation.

[arsv]

Context please? I'm not sure I'm following.

https://git.openembedded.org/openembedded-core/tree/meta/recipes-devtools/perl/perl_5.32.1.bb?id=f88e16f4e4f77f532502806246dda38dfbc1a1e5

I assume LICENSE and LIC_FILE_CHKSUM are used for the manifest, those look fine to me.

[kanavin]

http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=akanavin/package-version-updates&id=000c5f50f9a0b7c287d36988243b1b2779fcd04f

I'm splitting perl-cross into its own recipe, to ease updates and patch maintenance. That means it needs its own licensing info.

[arsv]

Ah ok I think I see the problem now. perl-cross is effectively a patchset for perl which just happens to be distributed as .tar.gz and not as .diff.gz. If it has to be made into a standalone package for maintenance reasons, well that's fine, but it needs to be acknowledged as an attempt to make a recipe containing a patch for another package.

Since file://README.md is already being added back to the distributable patchset, file://Artistic and file://Copying should probably get the same treatment. Another option is to clone git repo by tag, you'll get README.md, Artistic and Copying at the same time. Those three files are of the same kind as far as packaging is concerned.

I'm not exactly sure what prevents devtool update from handling this case properly, but at least to me it sounds like the issue is there.

[kanavin]

For reference, http://git.yoctoproject.org/cgit.cgi/poky-contrib/tree/meta/recipes-devtools/perl-cross/perlcross_1.3.6.bb?h=akanavin/package-version-updates is the recipe link that won't disappear on branch rebase.

[kanavin]

'devtool upgrade' can't handle upgrading recipes which pull several tarballs from different locations, it would have to be significantly reengineered for what is a rather marginal use case. It's far easier to split the additional tarballs into their own recipes and upgrade them as separate transactions.

The problem with re-adding README.md to the layer itself is that it won't catch the scenario when README.md is modified upstream in a way that affects the licensing terms - it's better to take it directly from the tarball. Very unikely with perl-cross, but still a potential problem.

[kanavin]

I can for sure switch over to fetching from git, if you prefer not to have those files in the tarballs, no problem with that.

[arsv]

https://github.com/arsv/perl-cross/archive/refs/tags/1.3.6.tar.gz
instead of
https://github.com/arsv/perl-cross/releases/download/1.3.6/perl-cross-1.3.6.tar.gz

[kanavin]

Sadly that won't work either. Those tarballs are auto-generated by github, and their checksums can, and do change spontaneously. Yocto specifically prohibits their use, and there's even an automated test for it.

[arsv]

Yikes. Well then git fetch by tag I guess.

Then patch and run 0pack.sh maybe to build the patchset .tar.gz and apply that onto the perl sources.
This way, the perl-cross recipe will be doing something at least.

But that's assuming you can do something with tar to make it reproducible.

Edit: or better yet, just put the tar command from 0pack into the recipe, modified as appropriate.

[kanavin]

No, there's no need to do that, the perl-cross recipe that I linked works perfectly. It unpacks and copies the content of the tarball into a sysroot ($sysroot/usr/share/perl-cross) for the perl itself, then the perl recipe takes that directory and copies it over its own source before starting the build. It's all fine, except for the lack of licensing info.