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