On Tue, Jan 18, 2022 at 9:27 AM Stefan Herbrechtsmeier <stefan.herbrechtsmeier-oss@...> wrote:
Am 18.01.2022 um 15:10 schrieb Bruce Ashfield:
On Tue, Jan 18, 2022 at 9:04 AM Richard Purdie <richard.purdie@...> wrote:
On Tue, 2022-01-18 at 15:00 +0100, Stefan Herbrechtsmeier wrote:
Am 18.01.2022 um 14:40 schrieb Richard Purdie:
On Tue, 2022-01-18 at 14:00 +0100, Stefan Herbrechtsmeier wrote:
In summary we use a language specific lock file based approach which support offline build, license checks and CVE scans and leaves the dependency management and fixing outside of OE to limit the recipe count and required resources.
I think so. It isn't the perfect solution but it is what will likely be the most successful/practical.
Should this be unified between Node.js / npm, Go, Rust / Cargo and Python / Pipfile?
I don't think it makes sense to dictate that and make a hard rule. Where there are many dependencies and we can't easily control the dependency mechanism in the language, yes. Not everything has as granular dependencies as npm though.
But do we have a consensus that we prefer existing lock files and a specific fetcher instead of a multi line SRC_URI generated by recipetool?
I think either can be acceptable, it really depends on the situation.
For go, I've been working on a generated SRC_URI (via a .inc file) for the source dependencies (but the low level tool to do that is outside of recipetool, as it is something simple and I don't want it bound into a larger tool's workflow).
If someone did figure it out within recipetool, I'd happily throw out my more focused effort (since it isn't done yet, and I'm not sure how long it will take to complete).
Do you extract the licenses from dependencies and populate the license checksums?
It's done at the source level, just the same way that we've been manually checking vendor/ subdirectories up until now (except better, since we can scan and checksum more easily). And that is done when generating the SRC_URI. Again, I'm only talking about go here, since that is where I spend most of my time in meta-virt. So this may be completely wrong for other languages or use cases I haven't run into.
Is it possible to see the code?
Do you prefer to populate the SRC_URI or would a direct use of the lock file inside a fetcher okay for you?
I use the SRC_URI, since I also use the fetcher prefix/subdir to position the clones where they will be picked up for the build, and that means the dependencies are very visible and part of a normal recipe hash/sstate/etc, But if similar functionality was possible via a language specific lock file, I wouldn't object.
Both solutions have advantages. The SRC_URI approach is known to OE developers but the manifest and lock file is supported by the language tools. I'm really unsure which way to go.
