[yocto] [Openembedded-architecture] Proposal: dealing with language-specific build tools/dependency management tools

[Alexander Kanavin]

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