Wiki - https://fedoraproject.org/wiki/Changes/NodeJSMetapackages
Discussion thread -
https://discussion.fedoraproject.org/t/f43-change-proposal-nodejs-metapackage-self-contained/157322
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: jsta...@redhat.com
* Name: [[User:aradchen|Andrei Radchenko]]
* Email: aradc...@redhat.com
* Name: [[User:tjuhasz|Tomas Juhasz]]
* Email: tjuh...@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
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
--
_______________________________________________
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
--
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
