On Wed, 2025-02-19 at 17:48 +0100, Stefan Herbrechtsmeier wrote: > > I don't change the exception. The exceptions are the reason for the > state of the series. > > The missing point is that the expectation is related to the end of a > dependency chain and not to a task itself. In any case the real > expectation isn't clear. What happens if the configuration need a > compiled source and it isn't feasible to create a native package. My > series satisfy the following expectations: > > * All sources are downloaded after the do_fetch > * All sources are unpacked after the do_unpack > * All sources are patched after the do_patch I could try and reply to all your points but this one jumps out as a really fundamental thing we disagree on. All our existing code assumes that:
"All sources are downloaded during do_fetch" which means once do_fetch runs, we have all the sources. That is quite different to what you say above. I fully appreciate it imposes quite some constraints but it doesn't change the fact that this is the situation. > WIP: > > do_fetch : run_fetch, > run_early_fetch, run_early_unpack, run_early_patch, run_resolve, > run_vendor_fetch > do_unpack: run_unpack, run_early_unpack, run_vendor_fetch > do_patch: run_patch, run_early_patch, run_vendor_patch > > The bitbake approach looks like the WIP but makes the run_early_patch > complicated or impossible. Which is why I'm saying that I'd prefer to do this in bitbake and if we have to drop that patching as a result, so be it. > > whether we need to have some kind of > > checksum to verify the "lockfile" is correct as originally intended in > > the recipe and probably more. > > > I want to prevent us from having the wrong motivation due to a lack > of understanding of the lock file. Why don't we add a look file > across all expanded URIs, regardless of the source of the URI, > because we could have the same problems in the other fetchers. > > > > > > I'm in the position of trying to mediate things (i.e. see the different > > viewpoints and bring people together, trying to find common ground) and > > yet at the same time, express views as someone who as spent a lot of > > years trying to maintain and improve this code. > > > I appreciate your work. > > But I sometimes have the feeling that the code is a patchwork quilt > and every attempt to replace several patches with something common is > met with rejection. We have a patchwork where people trust the current boundaries between the different pieces. You want to change the boundaries, and the assumptions made about those boundaries and replace it with something that isn't going to be easily understood by most of the userbase as the concepts are complex and break the existing models people work with. I'm doing my best to explain the problem but either I'm failing at that or we simply disagree on them. > > I have tried to seek help from the people who effectively oversee me as > > a maintainer (i.e. the TSC) with limited success. I'm not sure what to > > do from here. > > > > I really like to upstream my work because I think it would simplify > the package manager support, but there doesn't seem to be much > interest in the community for it. > People are too focused in their own problems to be able to spend enough time on these architectural type pieces. We do badly need this kind of work which is why I'm trying to help this move forward but equally we have to do it in a way which doesn't destablise our existing userbase, in other words we may have to make some compromises. I'd like to hope we pick the right ones. I'm worried as we have tried solutions for this space before and the fact we're discussing them again shows we haven't got it right yet. Cheers, Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#211720): https://lists.openembedded.org/g/openembedded-core/message/211720 Mute This Topic: https://lists.openembedded.org/mt/111229335/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
