Am 20.02.2025 um 11:00 schrieb Richard Purdie via lists.openembedded.org:
On Thu, 2025-02-20 at 10:48 +0100, Stefan Herbrechtsmeier wrote:
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.
The fetch task is the only task allowed to access the network and is
the only place where the sources should be being downloaded. Once the
do_fetch task completes, we have everything we need from the network
and no further network access is allowed.
I don't understand why the network need to be restricted to the do_fetch
task only but okay.
So yes, your assumption is therefore wrong. I'm focusing on this as if
we don't have that common understanding, nothing built upon those
different understandings is going to work.
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?
It would not be okay at all, no.
I want to fix existing gitsm problems which are independent of the
solution. We have duplicated code inside oe-core and need to fix them
for both solutions. Otherwise the sources from the lock file aren't
handle by the classes.
We have the archiver.bbclass, cargo_common.bbclass,
create-spdx-2.2.bbclass and spdx30_tasks.py files with use slightly
different code to receive the URIs and only one use the expanded list of
gitsm. How should I fix them?
I appreciate theoretical discussion is hard work but we've tried
taking patches in the past and we've ended up making things worse. I
can tell the direction you've been going isn't correct and is going to
lead to patches which are unable to be merged.
I've made it very very clear that the fetch module stays in bitbake
and that we need to find a way to support this in the fetch module,
not OE. Yes, that complicates things unfortunately but I have good
reasons for doing it, whether you understand or agree with them or
not. I'm not changing my mind on this.
Sorry, but I don't know how do go on. I don't understand the reasons nor
goals. I propose to change the code to remove code duplication and you
refuse it. I ask for the desired concept (pypi / go-vendor vs gomod) and
don't get a clear answer. I have a lot of improvements, harmonization
and fixes in the last series and doesn't know if they are desired.
I will say your original patch series against bitbake was probably a
lot closer to what I think we probably need. I didn't like the "magic"
going on to extend the data so perhaps if that piece were reworked and
made a more default/simpler/clearer part of the fetcher rather than
hidden, we'd probably reach some code we could agree on.
Which "magic" do you mean and what isn't clean enough?
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#211768):
https://lists.openembedded.org/g/openembedded-core/message/211768
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]
-=-=-=-=-=-=-=-=-=-=-=-
