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. 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 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. Cheers, Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#211247): https://lists.openembedded.org/g/openembedded-core/message/211247 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] -=-=-=-=-=-=-=-=-=-=-=-
