Re: [OE-core] [RFC PATCH 15/30] classes: add early fetch, unpack and patch support

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Tue, 2025-02-11 at 16:00 +0100, Stefan Herbrechtsmeier via lists.openembedded.org wrote:
> From: Stefan Herbrechtsmeier <stefan.herbrechtsmeier@weidmueller.com>
> 
> Add support for early fetch, unpack and patches task which run before
> normal patch task. This feature is useful to fetch additional
> dependencies based on a patched source before the normal unpack and
> patch tasks. The patch are marked as early via an early=1 parameter. An
> example use case is a patch for a package manager lock file (Cargo.lock,
> go.sum, package-lock.json).
> 
> Signed-off-by: Stefan Herbrechtsmeier <stefan.herbrechtsmeier@weidmueller.com>
> ---
> 
>  meta/classes-global/patch.bbclass | 17 +++++----
>  meta/classes-recipe/early.bbclass | 61 +++++++++++++++++++++++++++++++
>  meta/lib/oe/patch.py              | 10 +++--
>  3 files changed, 77 insertions(+), 11 deletions(-)
>  create mode 100644 meta/classes-recipe/early.bbclass

This level of complexity is going to cause massive headaches in future.
Having two fetch, two unpack and two patch tasks will ultimately just
cause a lot of confusion and make things like the SPDX code and
archiver code more complex too.

Rather than patching a cargo lock file, I'd probably prefer the correct
version be added in a later SRC_URI entry and used to overwrite the
earlier one at unpack time.

I appreciate the challenge there is then that fetcher isn't going to
know what it is fetching at fetch time though as it would potentially
be fetching with the unpatched lock file.

This is partly why we end up with the .inc files the way we do, then it
is explicit.  I'm not sure the fetcher can know deterministically what
it is fetching in advance without the .inc data though, which is one of
the concerns that have been expressed previously.

Cheers,

Richard