Am 12.02.2025 um 16:06 schrieb Richard Purdie:
On Wed, 2025-02-12 at 15:36 +0100, Stefan Herbrechtsmeier wrote:
My problem is the double standards. We support a fetcher which
dynamic resolve dependencies and without manual update step since
years. Nobody suggests to make the gitsm fetcher obsolete and
requests the users to run an update task after a SRC_URI change to
create a .inc file with the SRC_URIs of all the recursive submodules.
Nobody complains about the missing components in the recipe.
FWIW there have been problems and complaints about gitsm. There were
some people who explicitly converted gitsm recipes into git urls due to
issues with the fetcher.
We have on the most part dealt with the worst issues in gitsm now but
there are still some who don't use it.
With git there is at least a relatively wide understanding of the
technology. With many other areas like node, go and rust, the tools are
much younger without some of the features we sometimes need, at least
in the past and people's overall trust is much lower as a result.
At this point I'm not sure there would be demand to change gitsm but
there are still the concerns about that approach.
Whether we have hard requirements and introduce a git submodule
support which satisfy the requirements or we accept the advantages of
a simple user interface and minimize the disadvantages.
It doesn't matter if we run the resolve function inside a resolve,
fetch or update task. The questions is do we want to support dynamic
SRC_URIs or do we want an manual update task. The task needs to be
manual run after a SRC_URI change and can produces a lot of noise in
the update commit. In any case the manual editing of the SRC_URI
isn't practical and the users will use the package manager to update
dependencies and its recursive dependencies.
As a compromise we could add a new feature to generate .inc cache
files before the main bitbake run. This would eliminate the manual
update run and the commit noise as well as special fetch, unpack and
patch task.
I've partly being trying to channel some of the feelings I've been
hearing expressed in different places, as I do want any new solution to
meet the needs of the widest group we can. If the .inc is generated but
not checked in (to remove the commit noise), I suspect it loses some of
the value that people have wanted.
It would be helpful if more people participation in the discussion. It
is hard to understand why the .inc is needed if the lock file contains
the same information and common tools exists to manipulate the lock file.
I'm personally very torn. I get pushed many different ways, which
include robustness, simplicity and complexity reduction, performance
and various extremes of auditing. I feel I'm doing a bad job of trying
to represent everything :(.
I'm sorry for that.
I do see that there are basically two conflicting approaches and I'm
not sure everyone is going to be happy with either. This does worry me
a lot and puts me in a difficult place too.
Would you accept both solutions?
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#211263):
https://lists.openembedded.org/g/openembedded-core/message/211263
Mute This Topic: https://lists.openembedded.org/mt/111123548/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
