Re: [meta-oe][kirkstone][PATCH 1/1] Nodejs - Upgrade to 16.18.1


Martin Jansa
 

On Thu, Nov 24, 2022 at 7:06 PM Randy MacLeod <randy.macleod@...> wrote:
Add Armin to ensure he seems this once he recovers from US Thanksgiving indulgences.

On 2022-11-24 12:05, Martin Jansa wrote:
I see this is now queued in kirkstone-next

I see bunch of recipes failing since this upgrade landed in master, mostly due to npm dependency resolution being more strict now and builds failing with

npm ERR! code ERESOLVE
npm ERR! ERESOLVE could not resolve
...
npm ERR! Fix the upstream dependency conflict, or retry
npm ERR! this command with --force, or --legacy-peer-deps
npm ERR! to accept an incorrect (and potentially broken) dependency resolution.

Can we please delay backporting to kirkstone and langdale a bit more?

Seconded!

What recipes encounters this bug?


I've seen it in ~10 recipes, but all are internal and not available in any public layer. I've added --force to them as work around to see how many other recipes will start failing now.

There is one more failing from public layer:
but that's different issue, caused by the sysroot_stage_all:append() and new nodejs now installing node_gyp_bins with symlink to python3 causing:

ERROR: localization-tool-native-1.7.0-r7 do_populate_sysroot: sstate found an absolute path symlink /OE/work/x86_64-linux/localization-tool-native/1.7.0-r7/sysroot-destdir/OE/work/x86_64-linux/localization-tool-native/1.7.0-r7/recipe-sysroot-native/opt/js-loctool/node_modules/node-expat/build/node_gyp_bins/python3 pointing at /OE/hosttools/python3. Please replace this with a relative link.

But I haven't narrowed it down yet to see which exact nodejs/npm change caused this. And yes this recipe has other issues as well and doesn't even use npm.bbclass nor npmsw:// fetcher.


And if others are seeing similar failures please share them here as well.

The older nodejs was using npm@8.5.0, now its npm@8.19.2 more details about this change in behavior from 8.6.0 in https://github.com/npm/cli/issues/4998


Someone in the linked issue thread said:

       "We rolled back to Node v16.15.0, which has a working version of npm 8.5.5."

Should we drop the 16.18.x update and stick with 16.15.1 for kirkstone/langdale?


I don't mind keeping it in master, once I figure out how to fix it in master I wouldn't mind it getting backported to kirkstone and langdale as well.

This was just warning that this isn't just simple minor upgrade for some and at least some longer delay would be useful.


For master, I'd like to update to 18, 19, or ideally 20 if it's available before the end of M3.

Martin,

What version of node make sense to you for master?


I don't have strong opinion, we have a lot of ugly npm/nodejs recipes in webOS which need to be re-worked first, independently on nodejs version used. 

Do you agree that we should leave master on 16.18.x and people should fix their
'broken' npm dependencies?


Yes, from that npm bug it looks, that the old behavior was even worse than the current clear failure and the --force as work around seems to work reasonably well, so I don't mind keeping it in master and even eventually backporting it to kirkstone a bit later.

Cheers,

Join openembedded-devel@lists.openembedded.org to automatically receive all group messages.