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 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 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. Bruce > > If we use the lock files you have to manipulate the lock files. Is this > okay? -- - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end - "Use the force Harry" - Gandalf, Star Trek II
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#1439): https://lists.openembedded.org/g/openembedded-architecture/message/1439 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]] -=-=-=-=-=-=-=-=-=-=-=-
