Sounds fair. I’ll have a look. Thanks for pointing that out.

This is the harder issue that needs to be resolved and implemented first, before we start arguing about what is a good set of rules to apply. There is a already a linter that is integrated into the

Done :) A very short wrap-up for those who don’t have a GitHub account: I proposed to add oelint-adv to meta-openembedded as part of the GitHub CI pipeline. I know that many find oelint-adv too

Yes, except you aren't subscribed to the list, so your replies won't be seen by everyone, and you won't get replies that aren't CCd directly to you. Please take the trouble, and do embrace that awful

Marius, I know you want everyone to move to github and abandon email (seeing the previous thread), but asking everyone to go there for the 'discussion' won't get you far. Please write a proposal,

Sharing a copy of this to openembedded-architecture. Cheers, Richard

Am 18.01.2022 um 15:37 schrieb Bruce Ashfield: Is it possible to see the code? Both solutions have advantages. The SRC_URI approach is known to OE developers but the manifest and lock file is

Am 18.01.2022 um 15:32 schrieb Bruce Ashfield: The manifest and lock files are text, json or toml files. They list the name, version, url, checksum and sometimes path of every dependency. If we want

<stefan.herbrechtsmeier-oss@...> wrote: 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

<stefan.herbrechtsmeier-oss@...> wrote: 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

Am 18.01.2022 um 15:10 schrieb Bruce Ashfield: 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

Am 18.01.2022 um 15:06 schrieb Bruce Ashfield: 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

<richard.purdie@...> wrote: 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,

<richard.purdie@...> wrote: 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

I think either can be acceptable, it really depends on the situation. Cheers, Richard

Am 18.01.2022 um 14:40 schrieb Richard Purdie: 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 so. It isn't the perfect solution but it is what will likely be the most successful/practical. I don't think it makes sense to dictate that and make a hard rule. Where there are many

Hi Richard, Am 18.01.2022 um 11:26 schrieb Richard Purdie: In summary we use a language specific lock file based approach which support offline build, license checks and CVE scans and leaves the

Ideally we will need this information to be visible to our tools, yes. No. I deliberately tried to stress the most important things we needed to ensure. There are other important things too, e.g. the

Hi Alex, Am 18.01.2022 um 00:09 schrieb Alexander Kanavin: This fetcher calls the git fetcher and direct fetch the git submodule. I think we need the possibility to patch the dependency tree / lock