On 16/03/17 10:35, Alexander Kanavin wrote:
On 03/16/2017 11:30 AM, Paul Barker wrote:
Staying with NPM as the example, say we have a tree of 1000
dependencies for a top-level application recipe. I understand that
generating and then parsing 1000 recipes will bloat things and slow
down the build. However, we do need some way to apply patches to those
dependencies or fix metadata. For example, what if the license is
stated wrong on npmjs? What if the dependency list itself is wrong? What
I've always liked about OE is that you can fix this sort of problem in a
recipe when you need to.
Uhm, no. Separate recipes are simply not gonna work for npm, or Go, or
Rust without ugly hacking. Those 1000 deps are all pulled by 'npm
install' into the source tree of the thing you want to build and then
installed together with it into a private directory, having them as
separate recipes would mean that you need to fetch and install them
separately, which is simply not how npm operates.
You can still patch them dependencies just fine if there's just one
recipe; once they're pulled in, apply the patches.
Alex
An issue with not having separate recipes is going to cause problems
with OTA package updates. I currently have a node package that I
maintain for a client and it's so big (excess of 30,000 files with all
deps) that we have to have a special update procedure of uninstalling
the package, re-installing the new version and then performing a system
update. A package update with 30,000 files on a quad core fast arm64
chip takes upwards of 40 minutes. It would be fantastic, if only the
core node application and changed dependencies could be updated.
Would it be possible to use something similar to the 'auto-package'
stuff we already have to split out the inner package dependencies and
have specific packages for each dependency but not a separate recipe?
Cheers,
Jack.
--
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
