Re: [bitbake-devel] 'vendor' fetching discussion cont.

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

[-- Attachment #1: Type: text/plain, Size: 3861 bytes --]

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



[-- Attachment #2: Type: text/html, Size: 5541 bytes --]