On Wed, Feb 12, 2025 at 7:42 AM Stefan Herbrechtsmeier < stefan.herbrechtsmeier-...@weidmueller.com> wrote:
> > Am 11.02.2025 um 23:32 schrieb Bruce Ashfield via lists.openembedded.org: > > In message: [OE-core] [RFC PATCH 15/30] classes: add early fetch, unpack and > patch support > on 11/02/2025 Stefan Herbrechtsmeier via lists.openembedded.org wrote: > > > From: Stefan Herbrechtsmeier <stefan.herbrechtsme...@weidmueller.com> > <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). > > I understand why you need to do the above, but there's now multiple > fetch and patch tasks running throughout the pipeline of the > build and that's just more complexity to maintain. > > The tasks call the same functions and the difference is really low. The > early task simple use a filtered list of the SRC_URI. At the moment the > gitsm fetcher is doing the same but without a possibility to patch a > dependency. > > This is what I was asking about in some of my first replies > to the RFC series. When I've done this in the past, I'd just > suggest something simpler like the recipe provide a complete > "lock file" in the layer/recipe-space and have it overlayed > in the source. > > This was already supported by my first patch series. The disadvantage is a > lot of noise during each update. > > Of course that means it is in the same fetch task as what > will be fetching the vendor bits, but coordinating within > the single task is simpler in my experience (and it can > be checked on the SRC_URI). I haven't fully thought through > how to manage it, but wanted to reply to this while it was > fresh in my mind. > > It is simpler because you manual fetch the lock file, remove the > possibility to patch the file and skip the unpack. But you still need a > manual fetch, unpack and maybe patch the source and copy the file into the > meta layer. > That's a completely different type of complexity. Richard and I are only talking about the complexity after "bitbake <foo>" has been called. > > It is also possibility to integrate the early and resolve task into fetch > task but I'm unsure if this simplify the complexity. > Having direct calls to additional routines via conditional is less complex than tasks (dealing with timing, scheduling, code maintenance, etc), so that is preferable from at least my point of view. Bruce -- - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end - "Use the force Harry" - Gandalf, Star Trek II
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#211232): https://lists.openembedded.org/g/openembedded-core/message/211232 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] -=-=-=-=-=-=-=-=-=-=-=-
