We are reworking the Node.js packaging to make Node.js versions available as parallel-installable packages.
- Name: Stephen Gallagher
- Email: email@example.com
- Targeted release: Fedora Linux 38
- Last updated: 2022-09-26
- devel thread
- FESCo issue: #2869
- Tracker bug: #2130002
- Release notes tracker: #882
We will be creating the packages nodejs-16, nodejs-18 and (in April) nodejs-20. These packages will be parallel-installable (with the exception of the -devel subpackages) and provide
/usr/bin/node-$MAJOR. For each Fedora release, one source package will also generate a subpackage named
nodejs-$MAJOR-unversioned-command, which will represent the default version of Node.js for that release
Node.js applications packaged in Fedora are recommended to modify their startup scripts to point at an appropriate
/usr/bin/node-$MAJOR binary, to ensure compatibility even across release upgrades.
Neal Gompa raised the question of using a subpackage to own
/usr/bin/node instead of using the
alternatives subsystem, citing python as an example. My response was that the problem with this is that I want
/usr/bin/node to always be available so long as any
nodejs-$MAJOR version is installed. It also ensures that the
node(1) manpage always matches the
2022-09-14: After discussion on the list, this Change has been updated to drop the use of
update-alternatives and replace it with
nodejs-$MAJOR-unversioned-command. Additionally, we will be shipping an npm binary version-matched with each Node.js version.
Benefit to Fedora
- Provides a simple way to have a different (or multiple) Node.js interpreters on their system. No dealing with Modularity.
- Enables multiple versions of Node.js on the system (can test code against different versions without using containers)
- No more modules to maintain.
- Availability of multiple Node.js versions in the buildroot means that other
nodejs-*packages can test against multiple supported options.
- Proposal owners:
The packaging work is done and can be played with at https://copr.fedorainfracloud.org/coprs/sgallagh/nodejs-alternatives/ today.
- Other developers:
There should be no need to change any dependent packages, though packagers of Node.js software may wish to take advantage of the testing opportunities afforded.
2022-09-14: Packagers of Node applications will probably want to pin their application to a known-good Node.js release. This can be done by modifying the startup scripts to look for
- Release engineering: #Releng issue number
- Policies and guidelines: N/A (not needed for this Change)
We will be updating the Node.js Packaging Guidelines with the new best practices.
- Trademark approval: N/A (not needed for this Change)
- Alignment with Objectives:
Systems using the existing nodejs RPM package will be upgraded to the matching
nodejs-$MAJOR version. Work is pending on how to migrate users of Modular Node.js to the new packages.
How To Test
Done correctly, this should be handled entirely without the user's need to know about it.
- Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change)
- Contingency deadline: N/A (not a System Wide Change)
- Blocks release? N/A (not a System Wide Change), Yes/No
N/A (not a System Wide Change)
Multiple releases of Node.js may now be installed in parallel from the Fedora repositories.