On 03/10/2017 04:58 PM, Otavio Salvador wrote:

I'd like to avoid generating entire separate recipes though, because that
implies your custom-written tool would be figuring out where the dependency
source came from in the first place, and what are its own dependencies, when
creating the recipe, which can be tricky, breakage-prone guesswork.

In fact not; as you generate the recipes for the dependencies, it goes
recursively and is always good.

Would it also be true for npm, Rust, Go, and other languages that will come along? In your specific case the metadata may be easily available to parse and convert to recipe form, but this many not hold in other situations.

npm fetcher for instance was a nightmare to write, from what I've heard:

http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/bitbake/lib/bb/fetch2/npm.py

I want to use existing tools (like 'npm install') for getting the stuff from
the network - we don't really need full recipes, we just want to know the
licenses of the dependencies, and, if possible, lock them down to a specific
version.

Well we initially thought this would suffice but consider a security
flaw. As many apps may be using different versions of same package it
becomes a nightmare to figure which ones are affected. If using
dependencies it is fine, for free.

The lockdown files would list the versions of the dependencies (if it is possible, which is not always true), so you can inspect those to see if something is vulnerable. In node.js or Go worlds the libraries are not reused between apps anyway, so it really doesn't matter if they're packaged as separate recipes or not (I didn't have time to check Rust, but as it's also using lockdown files, I believe the libraries are not reused either).

Alex

_______________________________________________
Openembedded-architecture mailing list
Openembedded-architecture@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-architecture