| (5 intermediate revisions by 2 users not shown) | |||
| Line 2: | Line 2: | ||
= Node.js Repackaging = | = Node.js Repackaging = | ||
== Summary == | == Summary == | ||
| Line 24: | Line 22: | ||
== Current status == | == Current status == | ||
[[Category: | [[Category:ChangeAcceptedF38]] | ||
<!-- When your change proposal page is completed and ready for review and announcement --> | <!-- When your change proposal page is completed and ready for review and announcement --> | ||
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler --> | <!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler --> | ||
| Line 42: | Line 40: | ||
ON_QA -> change is fully code complete | ON_QA -> change is fully code complete | ||
--> | --> | ||
* FESCo issue: | * [https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/KCTAFBALWBWLNVC3HZIQ5DFIGEWQHNM2/ devel thread] | ||
* Tracker bug: | * FESCo issue: [https://pagure.io/fesco/issue/2869 #2869] | ||
* Release notes tracker: | * Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=2130002 #2130002] | ||
* Release notes tracker: [https://pagure.io/fedora-docs/release-notes/issue/882 #882] | |||
== Detailed Description == | == Detailed Description == | ||
<!-- Expand on the summary, if appropriate. A couple sentences suffices to explain the goal, but the more details you can provide the better. --> | <!-- Expand on the summary, if appropriate. A couple sentences suffices to explain the goal, but the more details you can provide the better. --> | ||
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`. | 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. | |||
== Feedback == | == Feedback == | ||
| Line 62: | Line 58: | ||
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 `/usr/bin/node` executable. | 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 `/usr/bin/node` executable. | ||
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 == | == Benefit to Fedora == | ||
| Line 110: | Line 108: | ||
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. | 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 `/usr/bin/node-$MAJOR` explicitly. | |||
* Release engineering: [https://pagure.io/releng/issues #Releng issue number] <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | * Release engineering: [https://pagure.io/releng/issues #Releng issue number] <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
Latest revision as of 20:12, 26 September 2022
Node.js Repackaging
Summary
We are reworking the Node.js packaging to make Node.js versions available as parallel-installable packages.
Owner
- Name: Stephen Gallagher
- Email: sgallagh@redhat.com
Current status
- Targeted release: Fedora Linux 38
- Last updated: 2022-09-26
- devel thread
- FESCo issue: #2869
- Tracker bug: #2130002
- Release notes tracker: #882
Detailed Description
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.
Feedback
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 /usr/bin/node executable.
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
User Benefits
- 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)
Packager Benefits
- 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.
Scope
- 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 /usr/bin/node-$MAJOR explicitly.
- 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:
N/A
Upgrade/compatibility impact
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
User Experience
Done correctly, this should be handled entirely without the user's need to know about it.
Dependencies
Contingency Plan
- 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
Documentation
N/A (not a System Wide Change)
Release Notes
Multiple releases of Node.js may now be installed in parallel from the Fedora repositories.