Am 19.02.2025 um 18:33 schrieb Richard Purdie:
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.
I don't get the point. Do you say that only the do_fetch is allow to
download anything? So my assumption that I can download something
outside the do_fetch task as long as the download happens if something
depend on the fetch task (like bitbake -c fetch ...) is wrong?
I don't understand that requirement but I can fulfill it. The only
consequence is a complex do_fetch task.
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.
But this is an essential feature because it simplify the usability. It
allows inexperienced user to fix a security issue in some minutes by
simple back port a patch from the upstream project or fix the problem
with common tools outside of oe.
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 don't change the boundaries. The boundaries are not clean at the
moment. Look at the code. Most users of the URIs assume that only the
SRC_URI exists. Because of gitsm this isn't true. But only the archiver
bbclass use it correct. The spdx classes notice it but fix it in a wrong
way. It simple replace the gitsm:// with a git:// and lose all the
dependent sources. I want to sharpen the concept by introduce a fetcher
/ source library in oe. The library abstract the bitbake fetcher details
and provide a simple api on top of it. This allows us to remove all the
duplicated code. The bitbake fetcher focus on the download and the oe
fetcher class on the management of the URIs. This allows use to
introduce new concept for the URI management and allows use to remove
the repeat instantiation and parsing of the SRC_URI.
Based on the code I would argue that the user base don't know that the
SRC_URI could be expand to additional URIs nor that a SRC_URI is
replaced by an other URI underneath. We have to fix this in any way and
I would take the opportunity to introduce a simpler and feature rich
solution.
We have a go-vendor bbclass and gomod fetcher. The first use the wget
and git fetcher and the second add a specific fetcher. We have two
solutions for the same problem with different concepts.
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.
I always try my best to not break existing users. Therefore I keep the
old behavior of the existing tasks or function calls. But we need to
sharpen the concepts and unify the code base. We have different
solutions (like go-vendor.bbclass and gomod.py) for the same problem and
partial integration of features (like expanded_urldata).
I think we have to much theoretical discussion and to less code. I would
like to integrate a Fetcher OE library to remove the redundant code,
unify the codebase and use the extended URIs where appropriate. This
would fix some existing problems and could help in the next step
independence of the solution. Would that be okay with you?
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#211749):
https://lists.openembedded.org/g/openembedded-core/message/211749
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]
-=-=-=-=-=-=-=-=-=-=-=-
