Am 11.02.2025 um 23:27 schrieb Richard Purdie:
On Tue, 2025-02-11 at 16:00 +0100, Stefan Herbrechtsmeier via
lists.openembedded.org wrote:
From: Stefan Herbrechtsmeier<stefan.herbrechtsme...@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.herbrechtsme...@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.
The tasks don't really increase the complexity. The fetch, unpack and
patch tasks work like before. The archiver and spdx classes are updated.
The main difference is that they use a function and not the SRC_URI
variable direct. The early tasks are only used by the vendor classes.
The old tasks handle all sources including the dynamic sources. The
early tasks works like the normal task but with a filtered source list.
Alternative the steps could be included into the resolve task.
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.
Is this really practical? In many cases you have to update the
dependencies of the dependency or other meta packages (.mod). It is much
easier to update the dependency via the package manager and create a
patch for the lock file. Take a look at patch 26.
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.
In worst case you have to patch the lock file so that the package
manager can create the vendor folder.
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.
The .inc file is generated from the lock file and the lock file contains
all required information inclusive check sums.
I'm unsure if the old process of updating a SRC_URI in a .inc file is
useful for package manager dependencies. The upstream project use
patches to update the dependency. The .inc file is auto generated and
any manual change need to be documented otherwise it is unclear how to
deal with the change during the next update. The changes in the .inc
file generate a lot of noise and complicate the review of manual updates.
Do we really need the possibility to change a SRC_URI outside of the
lock file if we integrate the package manager into devtool and allows
the user to manipulate the lock file via common tools and commands?
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#211228):
https://lists.openembedded.org/g/openembedded-core/message/211228
Mute This Topic: https://lists.openembedded.org/mt/111123537/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
