Am 18.01.2022 um 15:32 schrieb Bruce Ashfield:
On Tue, Jan 18, 2022 at 9:23 AM Stefan Herbrechtsmeier
<[email protected]> wrote:
Am 18.01.2022 um 15:06 schrieb Bruce Ashfield:
On Tue, Jan 18, 2022 at 8:40 AM Richard Purdie
<[email protected]> wrote:
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.
I think there might be a slight ambiguity in what people think of as
dependency management.
We've been allowing projects in go to carry their dependencies using
vendor/ directories since almost the beginning, but we have in the
past patched and updated those dependencies ourselves (by overlaying
the directory via clone, or by patching) to fix both bugs and CVEs.
Having the actual hashes specified by the main project repository and
than translated/transformed into something that our existing fetchers
can handle (both the fetch and placement into the appropriate
directory for language specific proxies/mirrors/search paths) isn't
really leaving the CVE and dependency management outside of OE. It is
leaving it outside of the OE package dependencies, but they are still
controlled, understood and something we can patch/manage within
recipes if required.
But this requires that you can patch lock files. Do we need to patch the
file or is it okay to place an alternative lock file beside the recipe
into the meta layer?
That depends if lock files are in the implementation I guess :)
The manifest and lock files are text, json or toml files. They list the
name, version, url, checksum and sometimes path of every dependency.
The requirement to patch a lock file would be language specific, (and
I know absolutely nothing about how NPM/rust/other does this), but
just like someone can modify a SRCREV in a bbappend, they would
be able to either override the SRC_URI or add an additional fetch and
overlay as required.
If we want to patch a dependency inside a manifest and lock file inside
the source we need an additional fetch and patch task after the unpack task.
If it was a lock file, I don't see why a secondary one couldn't be placed
in a layer like any other artifact and used (but of course would have
to be done before fetching, so that's more challenging) .. I can't say
that I have all the details straight in my mental model yet.
We could extract the information during recipe creation or fetch source.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#1441):
https://lists.openembedded.org/g/openembedded-architecture/message/1441
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]]
-=-=-=-=-=-=-=-=-=-=-=-
