Closed Bug 1716600 Opened 3 years ago Closed 3 years ago

The devtools debugger build uses my system's node instead of the one in mozbuild

Categories

(Firefox Build System :: General, defect, P3)

defect

Tracking

(firefox91 fixed)

RESOLVED FIXED
91 Branch
Tracking Status
firefox91 --- fixed

People

(Reporter: julienw, Assigned: mhentges)

Details

Attachments

(3 files)

The problem I see is when building the debugger source code, the lines I see in the output look like this:

0:30.42 Executing "/usr/bin/nodejs /home/julien/travail/git/mozilla-central-artifacts/devtools/client/shared/build/build.js /home/julien/travail/git/mozilla-central-artifacts/devtools/client/debugger/src/main.js /home/julien/travail/git/mozilla-central-artifacts/devtools/client/debugger/src/vendors.js /home/julien/travail/git/mozilla-central-artifacts/obj-x86_64-pc-linux-gnu-opt-artifact/dist/bin/browser/chrome/devtools/modules/devtools/client/debugger/src"

In the configure part of the build, I get:

 0:02.06 checking for nodejs... /usr/bin/nodejs (10.24.0)

I'm especially surprised because I see that ./mach bootstrap downloads a node installation (currently v10):

 0:02.82 Setting up artifact node.tar.zst
 0:02.82 Using artifact from local cache: /home/julien/.mozbuild/toolchains/6aef59b6410bef2e-node.tar.zst
 0:02.88 rm tree: /home/julien/.mozbuild/node
 0:03.06 untarring "/home/julien/.mozbuild/node.tar.zst"

(in this case it reused a previously downloaded version)

So why don't we use that one?

I still see the same thing after Bug 1716257.

I'm using Debian stable.

If you could apply https://gist.github.com/dmose/6a184eeaac89470424e274d1788913cd to your tree, and then try running ./mach configure and paste the relevant print output, that would be helpful...

Flags: needinfo?(felash)

(Answered on Slack)

Flags: needinfo?(felash)

As Dan asked on Slack, here is a quick summary of the story of the packaging of node in Debian (as I understand it).

In short, there used to be a problem because another package (called "node" with an executable /usr/sbin/node) existed before nodejs. This is some amateur packet radio. When they added a nodejs package providing /usr/bin/node binary both conflicted (logically, because they were in 2 different directories).

A reference to this conflict as well as the resolution to fix it is in the archive of this mail:
https://lists.debian.org/debian-devel-announce/2012/07/msg00002.html

In short: both packages will provide another binary than /usr/bin/node, and the user could install the package nodejs-legacy to link /usr/bin/node to /usr/bin/nodejs, or the package node to link /usr/sbin/node to /usr/sbin/ax25-node. Let's note that users upgrading from an older Debian version would keep the node binary from ax25-node.

I think this change was implemented for Debian 7 (Wheezy) that shipped in May 2013.

It was advised that packages support /usr/bin/nodejs rather than /usr/bin/node, probably because nodejs-legacy was supposed to be removed eventually. The logic on a Debian system is that everything is installed through packages, and so all packages relying with node would be modified to use nodejs rather than node. I believe that's why our build system was looking for nodejs in addition to node, because we were using it to build the Debian's firefox package;

Fast-forward nowadays.

Debian 8 (jessie) (oldoldstable, still supported as an LTS) is still in this situation. The LTS support ended in the end of June 2020.
Debian 9 (stretch) (oldstable, still supported as an LTS) still has these nodejs/nodejs-legacy packages, but node/ax25-node don't exist anymore. The LTS support ends in the end of June 2022. nodejs' version is v4. There's a v8 available with the "backports" distribution, this package provides /usr/bin/node directly.
Debian 10 (buster) is the current stable, shipped in July 2019. Now the nodejs package provides /usr/bin/node directly. nodejs is v10 in this version.
[Debian 11 (bullseye)]https://www.debian.org/releases/bullseye) hasn't shipped yet. Currently they have node v12.

Lastly the socalled "unstable" version is on node v12, and "experimental" has v14.

In my opinion, this means that if we depend on node v12 now, we can stop looking for the nodejs binary, because all versions that don't have the binary node are too old for our usage anyway, and we should unconditionally use the one downloaded to .mozbuild. There doesn't seem to have any downsides doing that.

But you'll want to ask glandium before changing some of this logic :-) I'm not sure what the Debian's guidelines are regarding building nowadays.

Priority: -- → P3
Assignee: nobody → mhentges
Status: NEW → ASSIGNED

As :julienw beautifully described on Bugzilla,
we no longer need to search for "nodejs" since all
packages providing Node >= v12 will provide the node
binary.

Base-toolchain tasks with Node v10 should still be
happy because, unlike Debian's Node v10, they provide
a node binary instead of nodejs.

Since we're no longer checking for both "nodejs" and "node",
find_executable() can be simplified.

Depends on D118375

In the existing behaviour, we would return a node/npm executable from
find_executable(), even if we couldn't extract a version from it or if
the extracted version was insufficient.

Now, we fail early if the detected node/npm is insufficient.

Depends on D118376

Pushed by mhentges@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/ebe3050c5d85
Always search for "node" instead of "nodejs" r=firefox-build-system-reviewers,nalexander
https://hg.mozilla.org/integration/autoland/rev/310cacf0f0b2
Remove looping from Node's find_executable() r=firefox-build-system-reviewers,nalexander
https://hg.mozilla.org/integration/autoland/rev/8f1f80e78411
Don't use node/npm that are too old or have no version r=firefox-build-system-reviewers,nalexander
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → 91 Branch
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: