Am 18.01.2022 um 15:10 schrieb Bruce Ashfield:
On Tue, Jan 18, 2022 at 9:04 AM Richard Purdie
<[email protected]> 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?

Do you prefer to populate the SRC_URI or would a direct use of the lock file inside a fetcher okay for you?
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#1438): 
https://lists.openembedded.org/g/openembedded-architecture/message/1438
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]]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to