Am 11.02.2025 um 22:46 schrieb Richard Purdie:
On Tue, 2025-02-11 at 16:00 +0100, Stefan Herbrechtsmeier via
lists.openembedded.org wrote:
From: Stefan Herbrechtsmeier<stefan.herbrechtsme...@weidmueller.com>
Signed-off-by: Stefan Herbrechtsmeier<stefan.herbrechtsme...@weidmueller.com>
---
.../python/python3-bcrypt-crates.inc | 84 -------------------
.../python/python3-bcrypt_4.2.1.bb | 4 +-
2 files changed, 1 insertion(+), 87 deletions(-)
delete mode 100644 meta/recipes-devtools/python/python3-bcrypt-crates.inc
So let me as the silly question. This removes the crates.inc file and
doesn't appear to add any kind of new list of locked down modules.
The list is generated on the fly like gitsm and doesn't require an extra
step.
This means that inspection tools just using the metadata can't see
"into" this recipe any longer for component information.
We support and use python code inside the variables and thereby need a
preprocessing of the metadata in any case.
What do you mean by "component information"?
This was
something that some people felt strongly that was a necessary part of
recipe metadata, for license, security and other manifest activities.
Why can't they use the SBOM for this?
Are we basically saying that information is now only available after
the build takes place?
They are only available after a special task run.
I'm very worried that the previous discussions didn't reach a
conclusion and this is moving the "magic" out of bitbake and into some
vendor classes without addressing the concerns previously raised about
transparency into the manifests of what is going on behind the scenes.
I try to address the concerns but don't realize that the missing
information in the recipe is a blocker.
This version gives the user the possibility to influence the
dependencies via patches or alternative lock file. It creates a vendor
folder for easy patch and debug. It integrates the dependencies into the
SBOM for security tracking.
I skipped the license topic for now because the package managers don't
handle license integrity. We have to keep the information in the recipe
but hopefully the license information doesn't change with each update.
I don't understand the requirement for the plain inspection. In my
opinion external tools should always use a defined output and shouldn't
depend on the project internal details. I adapt the existing users of
the SRC_URI to include the dynamic SRC_URIs.
I appreciate some of the requirements are conflicting.
For the record in some recent meetings, I was promised that help would
be forthcoming in helping guide this discussion. I therefore left
things alone in the hope that would happen. It simply hasn't, probably
due to time/work issues, which I can sympathise with but it does mean
I'm left doing a bad job of trying to respond to your patches whilst
trying to do too many other things badly too. That leaves us both very
frustrated.
I really want to see you succeed in reworking this and I appreciate the
time and effort put into the patches. To make this successful, I know
there are key stakeholders who need to buy into it and right now,
they're more likely just to keep doing their own things as it is easier
since this isn't going the direction they want. A key piece of making
this successful is negotiating something which can work for a
significant portion of them. I'm spelling all this out since I do at
least want to make the situation clear.
Yes, I'm very upset the OE community is putting me in this position
despite me repeatedly asking for help and that isn't your fault, which
just frustrates me more.
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.
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.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#211243):
https://lists.openembedded.org/g/openembedded-core/message/211243
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]
-=-=-=-=-=-=-=-=-=-=-=-
