Wiki - https://fedoraproject.org/wiki/Changes/NodeJSMetapackages Discussion thread - https://discussion.fedoraproject.org/t/f43-change-proposal-nodejs-metapackag...
This is a proposed Change for Fedora Linux. This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.
== Summary == The NodeJS team no longer wish to design one of the maintained NodeJS streams as the "default" or "preferred" one explicitly, but wishes for the users to retain the ability to install "any" NodeJS stream when the specific major version is not important to them. To that end, the non-versioned <code>nodejs</code> package will become an empty "metapackage" pulling one of the versioned nodejsXY packages as it's dependency.
== Owner == * Name: [[User:jstanek|Jan Stanek]] * Email: jstanek@redhat.com
* Name: [[User:aradchen|Andrei Radchenko]] * Email: aradchen@redhat.com
* Name: [[User:tjuhasz|Tomas Juhasz]] * Email: tjuhasz@redhat.com
== Detailed Description == This is a part of a larger iteration in a way we package NodeJS for Fedora and RHEL. The other parts are [[Changes/NodejsNodeModulesPath]] and [[Changes/NodejsAlternativesSystem]]. This change deals specifically with the ability to install '''any supported''' version of NodeJS, without specifying a major version.
Previously, this was achieved by selecting one of the streams as a "default" one. This stream then would produce ''only'' non-versioned rpms (<code>nodejs</code> vs. <code>nodejs22</code>), and thus be selected when doing <code># dnf install nodejs</code>. <code># dnf install nodejs22</code> also worked thanks to a virtual <code>Provides: nodejs22</code> specified in the spec file.
This approach works reasonably well, but also have several drawbacks:
<ol> <li>Producing ''only'' non-versioned rpms has various corner cases, such as breaking test assertions like <code># dnf install nodejs22; dnf list installed | grep nodejs22</code>.</li> <li> <p>There is no way to tell if a specific version was requested: results of <code># dnf install nodejs</code> and <code># dnf install nodejs22</code> are exactly the same.</p> <p>This means we have no way to infer whether it is "safe" to update the non-versioned rpms to another stream, and essentially forces us to have single default stream for the entire lifetime of the distribution. For Fedora itself, that is not that big of a problem, since the lifetime of a branched release roughly matches the span of upstream support for a LTS stream, but it becomes much larger problem in a long-living distribution such as RHEL.</p> </li> </ol>
To address these drawbacks, the following changes are proposed:
<ul> <li>All NodeJS streams will '''always''' produce full set of versioned rpms (<code>nodejs22 nodejs22-npm …</code>). The non-versioned rpms (<code>nodejs nodejs-npm …</code>) will be provided ''in addition'' to those above.</li> <li> <p>The non-versioned rpms (<code>nodejs</code>) rpms will explicitly represent the desire to have ''any'' stream installed, without any guarantees about which version gets installed or keeping that version the same during the entire lifetime of the distribution.</p> <p>(The working internal term for this non-guarantees and behavior is "rolling stream".)</p> </li> </ul>
It is assumed that the non-version rpms (the "metapackages") will always pull their versioned equivalent from one of the supported streams and be otherwise empty. Which specific stream they delegate to will be left to the maintainer's discretion and the needs of the specific distribution.
=== Implementation options ===
Currently, we are thinking about 2 possible ways to implement this change.
<ol> <li>Adding an extra set of sub-packages to the current SPEC file(s), hidden behind a <code>%bcond</code>. Only one of these <code>%bcond</code>s should ever be active at once. Simplified example: <pre> %bcond metapackages %[%{node_version_major} == %{nodejs_default_stream}] # %nodejs_default_stream presumably defined in nodejs-packaging globally ... %if %{with metapackages} %package -n nodejs Requires: nodejs%{node_version_major} = %{node_version} ... %endif </pre>
This would most closely mirror how the non-versioned packages are generated now. </li>
<li>Shipping separate empty package <code>nodejs</code>. <pre> Name: nodejs Version: 24 # the default stream Summary: nodejs metapackage Requires: nodejs%{version} ... </pre> </li> </ol>
We do not have a clear preference between those two, so feedback is welcome.
== Feedback ==
== Benefit to Fedora == We'll give users the option to choose between specific NodeJS stream and "any" NodeJS stream explicitly, and then work with the streams accordingly. Those wishing to have "any" NodeJS version available will always get (and keep) known-good version without worrying too much about which major version is currently supported, recommended, or chosen for them. Those wishing to have specific NodeJS stream can install one of the versioned stream explicitly and know that it will always stay on that particular major version.
== Scope == * Proposal owners: Change the non-versioned packages generation logic in the existing NodeJS packages to accommodate this change; optionally re-introduce new `nodejs` rpms.
* Other developers: Review their usage of `nodejs` and adjust them to comply with the new semantics.
* Release engineering: Should not be necessary.
* Policies and guidelines: Update to the new semantics of installation.
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact == A decision needs to be made to what kind of stream users with the current default stream installed will be migrated:
#. Treating current "default" stream as the "rolling" stream and simply update the installation to using the metapackages. #. Treating current "default" stream as weirdly named "specific" stream, and setting Obsoletes so that the installation would move to using the versioned packages (e.g. `nodejs` → `nodejs22`).
== Early Testing == After gathering initial round of feedback, a COPR will be set up, so that the changes can be tested before implementing them in the distribution proper.
== How To Test == #. Enable the COPR mentioned above. #. Try updating your NodeJS installation, or install new one from scratch. Brave testers might even tests rollbacks to previous versions.
== User Experience == * Ability to better select between NodeJS streams and have the selection honored going forward.
== Dependencies == N/A
== Contingency Plan ==
* Contingency mechanism: Not merging the Koji side tag. Keep using the (perhaps slightly tweaked) current approach, without any semantic changes.
* Contingency deadline: Beta freeze.
* Blocks release? No, asuming the builds and rebuilds will be done in separate environment (Koji side tag) and then merged atomically. Otherwise, YES.
== Documentation == This is a downstream initiative; documentation will need to be created, but that was already mentioned in the Policies and Guidelines bullet above.
== Release Notes == TODO