Hi Mark,
Am 14.01.2022 um 16:22 schrieb Mark Asselstine:
On 2022-01-14 10:05, Stefan Herbrechtsmeier wrote:
Am 14.01.2022 um 15:15 schrieb Mark Asselstine via
lists.openembedded.org:
On 2022-01-14 07:18, Alexander Kanavin wrote:
If we do seriously embark on making npm/go better, the first step
could be to make npm/go write out a reproducible manifest for the
licenses and sub-packages that can be verified against two recipe
checksums during fetch, and ensures no further network access is
necessary. That alone would make it a viable fetcher. Those
manifests could contain all needed information for further
processing (e.g. versions, and what depends on what etc.) And yes,
it's a bundled self-contained approach, but that matches how the
rest of the world is using npm.
I can't speak to npm but for go this was where I wanted to see things
go. Just as work was done to avoid unexpected downloads of Python
eggs I always felt the key to improving go integration was some for
of automated SRC_URI generation. Once this would be available it
could be leveraged for licensing and such.
Stefan, by the way the reason (a) is not possible is that multiple go
applications can use a shared 'library' but different versions (or
even different git commit ids).
Why is this simpler? The recipes need to list every information about
its dependencies. That means you repeat a lot of code and need to
change a lot of files if you update a single dependency.
We went through this with go recipes in meta-virt. It didn't work. You
end up producing a lot of Yocto Project specific files containing
information which is already available in other forms. Throw in the
multiple versions issue I described before and you get a mess.
I assume you want to use the version the project recommend and not a
single major version. What makes Go so special that the reasons for a
single major version are irrelevant? Why don't we use multiple version
for C/C++ projects?
Large
reviews of content that maintainers will have to waste time to determine
what is needed to review and what can be ignored as it is just
transposed information... Again, the key is automation, that is what
makes things simpler.
Without structured information any automation is impossible. Does the Go
manifest contains all the information a recipe needs (license, CVE
product name)?
What happens if we detect a CVE in a dependency? How can we fix it?
The number of recipes and versions of recipes required to support go
applications quickly becomes difficult to manage.
How one big recipe instead of multi small recipes can solve this problem?
I am not pushing a big recipe. Keep the go recipes much as they are now,
but leverage the go tools to generate support artifacts.
What are the artifacts?
Does the Go community need this artifacts too?
Regard
Stefan
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#1419):
https://lists.openembedded.org/g/openembedded-architecture/message/1419
Mute This Topic: https://lists.openembedded.org/mt/88417908/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
