https://fedoraproject.org/wiki/Changes/NodejsRepackaging
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 == We are reworking the Node.js packaging to make Node.js versions available as parallel-installable packages.
== Owner == * Name: [[User:SGallagh| Stephen Gallagher]] * Email: sgallagh@redhat.com
== 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`. We will also take advantage of the `alternatives` subsystem to populate `/usr/bin/node` from the default Node.js version for that release, or if the default is not installed, the highest currently-installed version.
Notes:
* The default in Fedora 38 will be Node.js 18. If a user was to install Node.js 16 and Node.js 20, but not Node.js 18, then Node.js 20 would provide `/usr/bin/node` * The policy going forward will be to have the most recently-released version of Node.js at the time of Fedora's expected Beta release date be the default for that release throughout its lifetime.
== Feedback == [https://lists.fedoraproject.org/archives/list/nodejs@lists.fedoraproject.org... Mailing list thread]
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.
== 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.
* Release engineering: * Policies and guidelines: 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)
== Documentation == https://lists.fedoraproject.org/archives/list/nodejs@lists.fedoraproject.org...
== Release Notes == Multiple releases of Node.js may now be installed in parallel from the Fedora repositories.
On Tue, Sep 06, 2022 at 02:28:39PM -0400, Ben Cotton wrote:
== Benefit to Fedora == === 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 ==
- 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.
How would I, as a packager, deal with this? Will RPM macros be changed? Should we start to build nodejs-XY-$package similar to how we have python3-$package (and previously python2-$package) from the source package python-$package?
What will the new RPM provides be? today it's simply npm($package) but I can imagine you want to change that to something versioned too.
On Tue, Sep 6, 2022 at 7:07 PM Ewoud Kohl van Wijngaarden ewoud+fedora@kohlvanwijngaarden.nl wrote:
On Tue, Sep 06, 2022 at 02:28:39PM -0400, Ben Cotton wrote:
== Benefit to Fedora == === 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 ==
- 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.
How would I, as a packager, deal with this? Will RPM macros be changed? Should we start to build nodejs-XY-$package similar to how we have python3-$package (and previously python2-$package) from the source package python-$package?
The only case where you might need to do this is if you're building an extension module that needs to be an arch-ful package. For the vast majority of Node modules, they are noarch.
What will the new RPM provides be? today it's simply npm($package) but I can imagine you want to change that to something versioned too.
See above; I don't think that will be needed in the vast majority of cases.
On Wed, Sep 07, 2022 at 12:31:27PM -0400, Stephen Gallagher wrote:
On Tue, Sep 6, 2022 at 7:07 PM Ewoud Kohl van Wijngaarden ewoud+fedora@kohlvanwijngaarden.nl wrote:
On Tue, Sep 06, 2022 at 02:28:39PM -0400, Ben Cotton wrote:
== Benefit to Fedora == === 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 ==
- 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.
How would I, as a packager, deal with this? Will RPM macros be changed? Should we start to build nodejs-XY-$package similar to how we have python3-$package (and previously python2-$package) from the source package python-$package?
The only case where you might need to do this is if you're building an extension module that needs to be an arch-ful package. For the vast majority of Node modules, they are noarch.
But what if $package a.b only supports node 16 and $package x.y only supports node 20. Looking at /usr/lib/node_modules/npm/node_modules I don't see any version numbers in directories so they can't be coinstalled. Does it mean you drop the node 16 package once node 20 is packaged? It will still be in the load path for node 16 so it could accidentally load incompatible code.
What will the new RPM provides be? today it's simply npm($package) but I can imagine you want to change that to something versioned too.
See above; I don't think that will be needed in the vast majority of cases.
That you say vast majority of cases means there are edge cases. I think a proposal needs to address those, even if it's saying that it becomes unsupported.
On Wed, Sep 7, 2022 at 1:36 PM Ewoud Kohl van Wijngaarden ewoud+fedora@kohlvanwijngaarden.nl wrote:
But what if $package a.b only supports node 16 and $package x.y only supports node 20. Looking at /usr/lib/node_modules/npm/node_modules I don't see any version numbers in directories so they can't be coinstalled. Does it mean you drop the node 16 package once node 20 is packaged? It will still be in the load path for node 16 so it could accidentally load incompatible code.
So, some of this is going to be resolved by policy. Currently, our official policy[1] on Node.js packages in Fedora allows packaging:
* The interpreter, development headers/libraries, and the assorted tools to manage project-level installations. Examples: nodejs, npm, yarn * Packages that provide applications that users would want to use in their shell. Examples: uglify
Note that we *expressly* do not list NPM "libraries". We only package applications. Further down on the guidelines page you will see that our packaging approach involves bundling the necessary dependencies into the application. This is in line with Node.js's own recommendations.
For developers working on Node.js software, they will be npm to install their dependencies into a node_modules subdirectory in their working directory. Those will be preferred over anything in the system path.
For the case of individual applications requiring a particular Node.js version, they should be packaged to run using the versioned /usr/bin/nodejs-X interpreter (and of course Requires: nodejs-X)
[1] https://docs.fedoraproject.org/en-US/packaging-guidelines/Node.js/#_what_to_...
What will the new RPM provides be? today it's simply npm($package) but I can imagine you want to change that to something versioned too.
See above; I don't think that will be needed in the vast majority of cases.
That you say vast majority of cases means there are edge cases. I think a proposal needs to address those, even if it's saying that it becomes unsupported. _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
* Stephen Gallagher:
On Wed, Sep 7, 2022 at 1:36 PM Ewoud Kohl van Wijngaarden ewoud+fedora@kohlvanwijngaarden.nl wrote:
But what if $package a.b only supports node 16 and $package x.y only supports node 20. Looking at /usr/lib/node_modules/npm/node_modules I don't see any version numbers in directories so they can't be coinstalled. Does it mean you drop the node 16 package once node 20 is packaged? It will still be in the load path for node 16 so it could accidentally load incompatible code.
So, some of this is going to be resolved by policy. Currently, our official policy[1] on Node.js packages in Fedora allows packaging:
- The interpreter, development headers/libraries, and the assorted
tools to manage project-level installations. Examples: nodejs, npm, yarn
- Packages that provide applications that users would want to use in
their shell. Examples: uglify
Note that we *expressly* do not list NPM "libraries". We only package applications. Further down on the guidelines page you will see that our packaging approach involves bundling the necessary dependencies into the application. This is in line with Node.js's own recommendations.
Ahh, this also explains why co-installable -devel packages are not required in the buildroot.
Thanks, Florian
On 06/09/2022 20:28, Ben Cotton wrote:
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 also take advantage of the `alternatives` subsystem to populate `/usr/bin/node` from the default Node.js version for that release, or if the default is not installed,
What about Fedora ostree variants?
The last time I asked about alternatives, I got an answer that it is a completely NO GO for immutable Fedora releases.
On Wed, Sep 7, 2022 at 2:49 AM Vitaly Zaitsev via devel devel@lists.fedoraproject.org wrote:
On 06/09/2022 20:28, Ben Cotton wrote:
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 also take advantage of the `alternatives` subsystem to populate `/usr/bin/node` from the default Node.js version for that release, or if the default is not installed,
What about Fedora ostree variants?
The last time I asked about alternatives, I got an answer that it is a completely NO GO for immutable Fedora releases.
That's one of the reasons why I'd prefer us to use a package to do it.
Each nodejs package could have a subpackage nodejs<vermajor>-unversioned-command, which has the following stanzas:
Provides: nodejs-unversioned-command Conflicts: nodejs-unversioned-command
And the default nodejs would have a "Requires: nodejs-unversioned-command" with a Suggests on the versioned package.
On Wed, Sep 7, 2022 at 9:03 AM Neal Gompa ngompa13@gmail.com wrote:
On Wed, Sep 7, 2022 at 2:49 AM Vitaly Zaitsev via devel devel@lists.fedoraproject.org wrote:
On 06/09/2022 20:28, Ben Cotton wrote:
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 also take advantage of the `alternatives` subsystem to populate `/usr/bin/node` from the default Node.js version for that release, or if the default is not installed,
What about Fedora ostree variants?
The last time I asked about alternatives, I got an answer that it is a completely NO GO for immutable Fedora releases.
That's one of the reasons why I'd prefer us to use a package to do it.
Each nodejs package could have a subpackage nodejs<vermajor>-unversioned-command, which has the following stanzas:
Provides: nodejs-unversioned-command Conflicts: nodejs-unversioned-command
And the default nodejs would have a "Requires: nodejs-unversioned-command" with a Suggests on the versioned package.
OK, this is new information for me. I'll have to ruminate on it.
As for OSTree, it sounds like the main problem is due to `update_alternatives` using `/var/lib/alternatives` for internal data. I may take a look and see how hard it would be to move that to `/etc/alternatives/state`.
On Wed, Sep 7, 2022 at 12:45 PM Stephen Gallagher sgallagh@redhat.com wrote:
On Wed, Sep 7, 2022 at 9:03 AM Neal Gompa ngompa13@gmail.com wrote:
On Wed, Sep 7, 2022 at 2:49 AM Vitaly Zaitsev via devel devel@lists.fedoraproject.org wrote:
On 06/09/2022 20:28, Ben Cotton wrote:
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 also take advantage of the `alternatives` subsystem to populate `/usr/bin/node` from the default Node.js version for that release, or if the default is not installed,
What about Fedora ostree variants?
The last time I asked about alternatives, I got an answer that it is a completely NO GO for immutable Fedora releases.
That's one of the reasons why I'd prefer us to use a package to do it.
Each nodejs package could have a subpackage nodejs<vermajor>-unversioned-command, which has the following stanzas:
Provides: nodejs-unversioned-command Conflicts: nodejs-unversioned-command
And the default nodejs would have a "Requires: nodejs-unversioned-command" with a Suggests on the versioned package.
OK, this is new information for me. I'll have to ruminate on it.
As for OSTree, it sounds like the main problem is due to `update_alternatives` using `/var/lib/alternatives` for internal data. I may take a look and see how hard it would be to move that to `/etc/alternatives/state`.
The openSUSE folks wrote an alternative alternatives implementation called libalternatives that is likely to be rpm-ostree compatible. It works differently from regular alternatives, and I've got a package in copr for it[1].
It might be worth exploring for this...
That said, I don't think alternatives makes sense for this case.
[1]: https://copr.fedorainfracloud.org/coprs/ngompa/alts/build/4815991/
-- 真実はいつも一つ！/ Always, there's only one truth!
On Wed, Sep 7, 2022 at 1:32 PM Neal Gompa ngompa13@gmail.com wrote:
On Wed, Sep 7, 2022 at 12:45 PM Stephen Gallagher sgallagh@redhat.com wrote:
On Wed, Sep 7, 2022 at 9:03 AM Neal Gompa ngompa13@gmail.com wrote:
On Wed, Sep 7, 2022 at 2:49 AM Vitaly Zaitsev via devel devel@lists.fedoraproject.org wrote:
On 06/09/2022 20:28, Ben Cotton wrote:
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 also take advantage of the `alternatives` subsystem to populate `/usr/bin/node` from the default Node.js version for that release, or if the default is not installed,
What about Fedora ostree variants?
The last time I asked about alternatives, I got an answer that it is a completely NO GO for immutable Fedora releases.
That's one of the reasons why I'd prefer us to use a package to do it.
Each nodejs package could have a subpackage nodejs<vermajor>-unversioned-command, which has the following stanzas:
Provides: nodejs-unversioned-command Conflicts: nodejs-unversioned-command
And the default nodejs would have a "Requires: nodejs-unversioned-command" with a Suggests on the versioned package.
OK, this is new information for me. I'll have to ruminate on it.
As for OSTree, it sounds like the main problem is due to `update_alternatives` using `/var/lib/alternatives` for internal data. I may take a look and see how hard it would be to move that to `/etc/alternatives/state`.
The openSUSE folks wrote an alternative alternatives implementation called libalternatives that is likely to be rpm-ostree compatible. It works differently from regular alternatives, and I've got a package in copr for it[1].
On both my Silverblue main system and Fedora IoT RPi system, /var/lib/alternatives is actually a symlink to ../../usr/lib/alternatives
I think that means that the alternatives system "works" but the user cannot change it. Maybe we can ask for that to move to ../../etc/alternatives/state instead?
It might be worth exploring for this...
That said, I don't think alternatives makes sense for this case.
Moving this conversation from nodejs@lists.fp.o to fedora-devel so we're not having the same discussion in two places... hopefully.
On Wed, Sep 7, 2022 at 12:01 PM Michael Dawson midawson@redhat.com wrote:
And 3 more for "stick with whatever ships with the version of node they're using"
On Wed, Sep 7, 2022 at 11:18 AM Michael Dawson midawson@redhat.com wrote:
So far from my internal question I have 3 people saying they stick to the shipped version for CI and update for their local development, and 2 others saying they stick to the shipped version.
On Wed, Sep 7, 2022 at 11:04 AM Neal Gompa ngompa13@gmail.com wrote:
On Wed, Sep 7, 2022 at 9:47 AM Michael Dawson midawson@redhat.com wrote:
Would that differ from the general ecosystem? The npm command itself
tells you to run `npm update -g` to grab the latest version every time you run it, so I would assume many/most people would already be running the latest npm against whichever Node version they were using. Am I mistaken?
I don't think that is the case. I believe most people stick with the version that has been validated/shipped with Node.js itself. I'll ask in our Node.js/JavaScript chat room to see what other people think.
At least at my workplace, nobody does that. npm is packaged and upgraded independently of nodejs.
Okay, with that in mind, I guess I'll revise the plan to include npm from the Node tarball and add that to the set of executables in the alternatives system.
I'm still thinking over Neal's suggestion about a nodejsX-unversioned-package option. It's pretty similar in practice to the alternatives approach, except for three points:
1. If the user wants to change the default Node version, they have to do `dnf swap nodejs16-unversioned-command nodejs18-unversioned-command` rather than call `/usr/sbin/update-alternatives` (opinion: roughly equivalent difficulty, maybe a slight edge to the unversioned-command approach) 2. With alternatives, we can be opinionated as to which version should be preferred as the default if multiple versions are installed, whereas with the unversioned-command, it always has to be a user decision (Suggests: notwithstanding) 3. It makes the packaging of npm more complicated. a. Do we make the nodejsX-unversioned-command pull in the matching npm package? b. Do we allow users to mix-and-match the npm default independently to Node.js?
On Wed, Sep 7, 2022 at 1:41 PM Stephen Gallagher sgallagh@redhat.com wrote:
On Wed, Sep 7, 2022 at 1:32 PM Neal Gompa ngompa13@gmail.com wrote:
On Wed, Sep 7, 2022 at 12:45 PM Stephen Gallagher sgallagh@redhat.com wrote:
On Wed, Sep 7, 2022 at 9:03 AM Neal Gompa ngompa13@gmail.com wrote:
On Wed, Sep 7, 2022 at 2:49 AM Vitaly Zaitsev via devel devel@lists.fedoraproject.org wrote:
On 06/09/2022 20:28, Ben Cotton wrote:
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 also take advantage of the `alternatives` subsystem to populate `/usr/bin/node` from the default Node.js version for that release, or if the default is not installed,
What about Fedora ostree variants?
The last time I asked about alternatives, I got an answer that it is a completely NO GO for immutable Fedora releases.
That's one of the reasons why I'd prefer us to use a package to do it.
Each nodejs package could have a subpackage nodejs<vermajor>-unversioned-command, which has the following stanzas:
Provides: nodejs-unversioned-command Conflicts: nodejs-unversioned-command
And the default nodejs would have a "Requires: nodejs-unversioned-command" with a Suggests on the versioned package.
OK, this is new information for me. I'll have to ruminate on it.
As for OSTree, it sounds like the main problem is due to `update_alternatives` using `/var/lib/alternatives` for internal data. I may take a look and see how hard it would be to move that to `/etc/alternatives/state`.
The openSUSE folks wrote an alternative alternatives implementation called libalternatives that is likely to be rpm-ostree compatible. It works differently from regular alternatives, and I've got a package in copr for it[1].
On both my Silverblue main system and Fedora IoT RPi system, /var/lib/alternatives is actually a symlink to ../../usr/lib/alternatives
I think that means that the alternatives system "works" but the user cannot change it. Maybe we can ask for that to move to ../../etc/alternatives/state instead?
It might be worth exploring for this...
That said, I don't think alternatives makes sense for this case.
Moving this conversation from nodejs@lists.fp.o to fedora-devel so we're not having the same discussion in two places... hopefully.
On Wed, Sep 7, 2022 at 12:01 PM Michael Dawson midawson@redhat.com wrote:
And 3 more for "stick with whatever ships with the version of node they're using"
On Wed, Sep 7, 2022 at 11:18 AM Michael Dawson midawson@redhat.com wrote:
So far from my internal question I have 3 people saying they stick to the shipped version for CI and update for their local development, and 2 others saying they stick to the shipped version.
On Wed, Sep 7, 2022 at 11:04 AM Neal Gompa ngompa13@gmail.com wrote:
On Wed, Sep 7, 2022 at 9:47 AM Michael Dawson midawson@redhat.com wrote:
Would that differ from the general ecosystem? The npm command itself
tells you to run `npm update -g` to grab the latest version every time you run it, so I would assume many/most people would already be running the latest npm against whichever Node version they were using. Am I mistaken?
I don't think that is the case. I believe most people stick with the version that has been validated/shipped with Node.js itself. I'll ask in our Node.js/JavaScript chat room to see what other people think.
At least at my workplace, nobody does that. npm is packaged and upgraded independently of nodejs.
Okay, with that in mind, I guess I'll revise the plan to include npm from the Node tarball and add that to the set of executables in the alternatives system.
I'm still thinking over Neal's suggestion about a nodejsX-unversioned-package option. It's pretty similar in practice to the alternatives approach, except for three points:
- If the user wants to change the default Node version, they have to
do `dnf swap nodejs16-unversioned-command nodejs18-unversioned-command` rather than call `/usr/sbin/update-alternatives` (opinion: roughly equivalent difficulty, maybe a slight edge to the unversioned-command approach) 2. With alternatives, we can be opinionated as to which version should be preferred as the default if multiple versions are installed, whereas with the unversioned-command, it always has to be a user decision (Suggests: notwithstanding) 3. It makes the packaging of npm more complicated. a. Do we make the nodejsX-unversioned-command pull in the matching npm package? b. Do we allow users to mix-and-match the npm default independently to Node.js?
3a. If you want to, though I thought you decoupled npm already. I reviewed a split out npm package, so I assume we're not multiversioning npm anymore. 3b. I think by virtue of the split npm package, we are?
On Wed, Sep 7, 2022 at 1:56 PM Neal Gompa ngompa13@gmail.com wrote:
On Wed, Sep 7, 2022 at 1:41 PM Stephen Gallagher sgallagh@redhat.com wrote:
On Wed, Sep 7, 2022 at 1:32 PM Neal Gompa ngompa13@gmail.com wrote:
On Wed, Sep 7, 2022 at 12:45 PM Stephen Gallagher sgallagh@redhat.com wrote:
On Wed, Sep 7, 2022 at 9:03 AM Neal Gompa ngompa13@gmail.com wrote:
On Wed, Sep 7, 2022 at 2:49 AM Vitaly Zaitsev via devel devel@lists.fedoraproject.org wrote:
On 06/09/2022 20:28, Ben Cotton wrote: > 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 also take advantage of the > `alternatives` subsystem to populate `/usr/bin/node` from the default > Node.js version for that release, or if the default is not installed,
What about Fedora ostree variants?
The last time I asked about alternatives, I got an answer that it is a completely NO GO for immutable Fedora releases.
That's one of the reasons why I'd prefer us to use a package to do it.
Each nodejs package could have a subpackage nodejs<vermajor>-unversioned-command, which has the following stanzas:
Provides: nodejs-unversioned-command Conflicts: nodejs-unversioned-command
And the default nodejs would have a "Requires: nodejs-unversioned-command" with a Suggests on the versioned package.
OK, this is new information for me. I'll have to ruminate on it.
As for OSTree, it sounds like the main problem is due to `update_alternatives` using `/var/lib/alternatives` for internal data. I may take a look and see how hard it would be to move that to `/etc/alternatives/state`.
The openSUSE folks wrote an alternative alternatives implementation called libalternatives that is likely to be rpm-ostree compatible. It works differently from regular alternatives, and I've got a package in copr for it[1].
On both my Silverblue main system and Fedora IoT RPi system, /var/lib/alternatives is actually a symlink to ../../usr/lib/alternatives
I think that means that the alternatives system "works" but the user cannot change it. Maybe we can ask for that to move to ../../etc/alternatives/state instead?
It might be worth exploring for this...
That said, I don't think alternatives makes sense for this case.
Moving this conversation from nodejs@lists.fp.o to fedora-devel so we're not having the same discussion in two places... hopefully.
On Wed, Sep 7, 2022 at 12:01 PM Michael Dawson midawson@redhat.com wrote:
And 3 more for "stick with whatever ships with the version of node they're using"
On Wed, Sep 7, 2022 at 11:18 AM Michael Dawson midawson@redhat.com wrote:
So far from my internal question I have 3 people saying they stick to the shipped version for CI and update for their local development, and 2 others saying they stick to the shipped version.
On Wed, Sep 7, 2022 at 11:04 AM Neal Gompa ngompa13@gmail.com wrote:
On Wed, Sep 7, 2022 at 9:47 AM Michael Dawson midawson@redhat.com wrote:
> Would that differ from the general ecosystem? The npm command itself tells you to run `npm update -g` to grab the latest version every time you run it, so I would assume many/most people would already be running the latest npm against whichever Node version they were using. Am I mistaken?
I don't think that is the case. I believe most people stick with the version that has been validated/shipped with Node.js itself. I'll ask in our Node.js/JavaScript chat room to see what other people think.
At least at my workplace, nobody does that. npm is packaged and upgraded independently of nodejs.
Okay, with that in mind, I guess I'll revise the plan to include npm from the Node tarball and add that to the set of executables in the alternatives system.
I'm still thinking over Neal's suggestion about a nodejsX-unversioned-package option. It's pretty similar in practice to the alternatives approach, except for three points:
- If the user wants to change the default Node version, they have to
do `dnf swap nodejs16-unversioned-command nodejs18-unversioned-command` rather than call `/usr/sbin/update-alternatives` (opinion: roughly equivalent difficulty, maybe a slight edge to the unversioned-command approach) 2. With alternatives, we can be opinionated as to which version should be preferred as the default if multiple versions are installed, whereas with the unversioned-command, it always has to be a user decision (Suggests: notwithstanding) 3. It makes the packaging of npm more complicated. a. Do we make the nodejsX-unversioned-command pull in the matching npm package? b. Do we allow users to mix-and-match the npm default independently to Node.js?
3a. If you want to, though I thought you decoupled npm already. I reviewed a split out npm package, so I assume we're not multiversioning npm anymore. 3b. I think by virtue of the split npm package, we are?
I prepared a decoupled npm package but I haven't actually built it in Fedora yet, so we're not committed to it.
Dne 07. 09. 22 v 19:41 Stephen Gallagher napsal(a):
On Wed, Sep 7, 2022 at 1:32 PM Neal Gompa ngompa13@gmail.com wrote:
On Wed, Sep 7, 2022 at 12:45 PM Stephen Gallagher sgallagh@redhat.com wrote:
On Wed, Sep 7, 2022 at 9:03 AM Neal Gompa ngompa13@gmail.com wrote:
On Wed, Sep 7, 2022 at 2:49 AM Vitaly Zaitsev via devel devel@lists.fedoraproject.org wrote:
On 06/09/2022 20:28, Ben Cotton wrote:
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 also take advantage of the `alternatives` subsystem to populate `/usr/bin/node` from the default Node.js version for that release, or if the default is not installed,
What about Fedora ostree variants?
The last time I asked about alternatives, I got an answer that it is a completely NO GO for immutable Fedora releases.
That's one of the reasons why I'd prefer us to use a package to do it.
Each nodejs package could have a subpackage nodejs<vermajor>-unversioned-command, which has the following stanzas:
Provides: nodejs-unversioned-command Conflicts: nodejs-unversioned-command
And the default nodejs would have a "Requires: nodejs-unversioned-command" with a Suggests on the versioned package.
OK, this is new information for me. I'll have to ruminate on it.
As for OSTree, it sounds like the main problem is due to `update_alternatives` using `/var/lib/alternatives` for internal data. I may take a look and see how hard it would be to move that to `/etc/alternatives/state`.
The openSUSE folks wrote an alternative alternatives implementation called libalternatives that is likely to be rpm-ostree compatible. It works differently from regular alternatives, and I've got a package in copr for it[1].
On both my Silverblue main system and Fedora IoT RPi system, /var/lib/alternatives is actually a symlink to ../../usr/lib/alternatives
I think that means that the alternatives system "works" but the user cannot change it. Maybe we can ask for that to move to ../../etc/alternatives/state instead?
It might be worth exploring for this...
That said, I don't think alternatives makes sense for this case.
Moving this conversation from nodejs@lists.fp.o to fedora-devel so we're not having the same discussion in two places... hopefully.
On Wed, Sep 7, 2022 at 12:01 PM Michael Dawson midawson@redhat.com wrote:
And 3 more for "stick with whatever ships with the version of node they're using"
On Wed, Sep 7, 2022 at 11:18 AM Michael Dawson midawson@redhat.com wrote:
So far from my internal question I have 3 people saying they stick to the shipped version for CI and update for their local development, and 2 others saying they stick to the shipped version.
On Wed, Sep 7, 2022 at 11:04 AM Neal Gompa ngompa13@gmail.com wrote:
On Wed, Sep 7, 2022 at 9:47 AM Michael Dawson midawson@redhat.com wrote:
Would that differ from the general ecosystem? The npm command itself
tells you to run `npm update -g` to grab the latest version every time you run it, so I would assume many/most people would already be running the latest npm against whichever Node version they were using. Am I mistaken?
I don't think that is the case. I believe most people stick with the version that has been validated/shipped with Node.js itself. I'll ask in our Node.js/JavaScript chat room to see what other people think.
At least at my workplace, nobody does that. npm is packaged and upgraded independently of nodejs.
Okay, with that in mind, I guess I'll revise the plan to include npm from the Node tarball and add that to the set of executables in the alternatives system.
I'm still thinking over Neal's suggestion about a nodejsX-unversioned-package option.
Just FTR, in Ruby we are using `Provides: ruby(runtime_executable) = %{ruby_release}` [1] for the similar purpose. This comes from the days we had JRuby available as and alternative implementation.
BTW I don't want to derails this discussion too much, but there are also alternative JS runtimes to Node.js, maybe it would make sense to consider them.
Vít
[1] https://src.fedoraproject.org/rpms/ruby/blob/c2026da1750e6d0cc70c7370a084062...
It's pretty similar in practice to the alternatives approach, except for three points:
- If the user wants to change the default Node version, they have to
do `dnf swap nodejs16-unversioned-command nodejs18-unversioned-command` rather than call `/usr/sbin/update-alternatives` (opinion: roughly equivalent difficulty, maybe a slight edge to the unversioned-command approach) 2. With alternatives, we can be opinionated as to which version should be preferred as the default if multiple versions are installed, whereas with the unversioned-command, it always has to be a user decision (Suggests: notwithstanding) 3. It makes the packaging of npm more complicated. a. Do we make the nodejsX-unversioned-command pull in the matching npm package? b. Do we allow users to mix-and-match the npm default independently to Node.js? _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
On 07. 09. 22 19:30, Neal Gompa wrote:
That said, I don't think alternatives makes sense for this case.
Me neither. We used this for /usr/bin/python3 in RHEL 8 and it's very bad UX and requires custom hacks in scriptlets even in RHEL 9 to undo it. It's ugly and hard to get rid of.
See https://docs.fedoraproject.org/en-US/packaging-guidelines/Alternatives/
""" Alternatives MAY be used to allow parallel installation of software when:
the software can be used as a drop-in replacement and functions with sufficient similarity that users and other programs would, within reason, not need to know which variant is currently installed """
Not exactly the case here.
""" AND
the selection of the software is only performed system-wide by the system administrator and end users do not have a need to switch between the variants. """
Not exactly the case here either.
Happy to talk to you about other options next week. Just noting this now here fast before I leave for a conference for the rest of this week.
On Wed, Sep 7, 2022 at 3:30 PM Miro Hrončok mhroncok@redhat.com wrote:
On 07. 09. 22 19:30, Neal Gompa wrote:
That said, I don't think alternatives makes sense for this case.
Me neither. We used this for /usr/bin/python3 in RHEL 8 and it's very bad UX and requires custom hacks in scriptlets even in RHEL 9 to undo it. It's ugly and hard to get rid of.
See https://docs.fedoraproject.org/en-US/packaging-guidelines/Alternatives/
""" Alternatives MAY be used to allow parallel installation of software when:
the software can be used as a drop-in replacement and functions withsufficient similarity that users and other programs would, within reason, not need to know which variant is currently installed """
Not exactly the case here.
""" AND
the selection of the software is only performed system-wide by the systemadministrator and end users do not have a need to switch between the variants. """
Not exactly the case here either.
Happy to talk to you about other options next week. Just noting this now here fast before I leave for a conference for the rest of this week.
I was thinking about this some more and I have a modified proposal that I'd like to suggest. It will be much the same as the original, but with the following changes:
* We will stop shipping an independent `npm` subpackage and ship /usr/bin/npm-$NODE_VERSION in the `nodejs-$NODE_VERSION` package. * Instead of the `update-alternatives` system, each `nodejs-$NODE_VERSION` still in support will ship a `nodejs-$NODE_VERSION-default` subpackage that will conflict with other packages that `Provides: nodejs-default`. It will provide the /usr/bin/node and /usr/bin/npm symlinks to the matching $NODE_VERSION * When a particular version of Node.js goes out of support before the EOL of that Fedora release, we will have the main `nodejs-$NODE_VERSION` subpackage add `Obsoletes: nodejs-$NODE_VERSION-default < <this_release>`. We will still ship the `-default` subpackage, but it will have to be reinstalled intentionally once the EOL is reached.[1]
The general idea here would be to allow end-users to pick whichever installed version they want to own /usr/bin/node and /usr/bin/npm, as well as binding those two executables tightly together[2]. In addition, it would offer us an opportunity to be noisy about the EOL date. The downside to this, of course, is that it could be annoying to our users that they need to take manual action to remain on an EOL Node.js version (as /usr/bin/node).
WDYT?
[1] If we want to be more picky, we could change the subpackage to `-eol-default` rather than just `-default` once the EOL is reached, in addition to adding the `Obsoletes:` to the main package. [2] The `npm update -g npm` command will still allow this to be overridden.
On 12. 09. 22 20:56, Stephen Gallagher wrote:
On Wed, Sep 7, 2022 at 3:30 PM Miro Hrončok mhroncok@redhat.com wrote:
On 07. 09. 22 19:30, Neal Gompa wrote:
That said, I don't think alternatives makes sense for this case.
Me neither. We used this for /usr/bin/python3 in RHEL 8 and it's very bad UX and requires custom hacks in scriptlets even in RHEL 9 to undo it. It's ugly and hard to get rid of.
See https://docs.fedoraproject.org/en-US/packaging-guidelines/Alternatives/
""" Alternatives MAY be used to allow parallel installation of software when:
the software can be used as a drop-in replacement and functions withsufficient similarity that users and other programs would, within reason, not need to know which variant is currently installed """
Not exactly the case here.
""" AND
the selection of the software is only performed system-wide by the systemadministrator and end users do not have a need to switch between the variants. """
Not exactly the case here either.
Happy to talk to you about other options next week. Just noting this now here fast before I leave for a conference for the rest of this week.
I was thinking about this some more and I have a modified proposal that I'd like to suggest. It will be much the same as the original, but with the following changes:
- We will stop shipping an independent `npm` subpackage and ship
/usr/bin/npm-$NODE_VERSION in the `nodejs-$NODE_VERSION` package.
- Instead of the `update-alternatives` system, each
`nodejs-$NODE_VERSION` still in support will ship a `nodejs-$NODE_VERSION-default` subpackage that will conflict with other packages that `Provides: nodejs-default`. It will provide the /usr/bin/node and /usr/bin/npm symlinks to the matching $NODE_VERSION
- When a particular version of Node.js goes out of support before the
EOL of that Fedora release, we will have the main `nodejs-$NODE_VERSION` subpackage add `Obsoletes: nodejs-$NODE_VERSION-default < <this_release>`. We will still ship the `-default` subpackage, but it will have to be reinstalled intentionally once the EOL is reached.[1]
The general idea here would be to allow end-users to pick whichever installed version they want to own /usr/bin/node and /usr/bin/npm, as well as binding those two executables tightly together[2]. In addition, it would offer us an opportunity to be noisy about the EOL date. The downside to this, of course, is that it could be annoying to our users that they need to take manual action to remain on an EOL Node.js version (as /usr/bin/node).
WDYT?
[1] If we want to be more picky, we could change the subpackage to `-eol-default` rather than just `-default` once the EOL is reached, in addition to adding the `Obsoletes:` to the main package. [2] The `npm update -g npm` command will still allow this to be overridden.
I don't like the EOL-Obsolte within one Fedora release. Things like this should only change on release boundary. Other than that it sounds good, but consider that packages requiring /usr/bin/node might pick any of the versions we ship. Something might need to Suggest the one we prefer.
In Python, we deliberately decided that RPM-packaged software only uses one version at one particular Fedora release. Do you wish to support RPMs to use arbitrary versions including "doesn't matter"?
Depending on the answer of that questions, I might give more suggestions inspired by Python, or think about how to do it differently.
On Mon, Sep 12, 2022 at 3:34 PM Miro Hrončok mhroncok@redhat.com wrote: ...
I don't like the EOL-Obsolte within one Fedora release. Things like this should only change on release boundary. Other than that it sounds good, but consider that packages requiring /usr/bin/node might pick any of the versions we ship. Something might need to Suggest the one we prefer.
Yeah, I think we'd do `Suggests: <whatever is the latest stable at Fedora Beta>`.
In Python, we deliberately decided that RPM-packaged software only uses one version at one particular Fedora release. Do you wish to support RPMs to use arbitrary versions including "doesn't matter"?
The reality of the ecosystem is that many applications lag in their support for stable Node.js releases by months. So I think I'd want us to be able to package FooApp that relies on Node.js 16 even if the "default" for the release is Node.js 18. This should require that they modify the RPM packaged application to explicitly look for /usr/bin/node-16, rather than /usr/bin/node. Thinking about it more, I think we'd probably want to have *all* applications pin to their preferred Node.js runtime and reserve /usr/bin/node for developer convenience.
It does beg the question of what to do with an application that adds support for a newer Node.js runtime mid-Fedora-lifecycle. Do we require them to stick with the initial interpreter for the life of that release to avoid pulling in another runtime on upgrade, or do we allow them to jump to the newer version?
Depending on the answer of that questions, I might give more suggestions inspired by Python, or think about how to do it differently.
I've updated https://fedoraproject.org/wiki/Changes/NodejsRepackaging with the results of this discussion. I'll go the `nodejs-$MAJOR-unversioned-command` route.
As I'm implementing this, I'm realizing that it probably only makes sense to have the default version of Node.js on each Fedora release provide the unversioned-command. Otherwise it becomes really hard to ensure that the RPM macros like %{nodejs_sitelib} refer to the correct location. So I think I'll stick with "if you're packaging for Fedora, it has to work on the default Node release *or* you must deal with everything yourself if you need to run on a different runtime".
On Wed, Sep 14, 2022 at 3:38 PM Stephen Gallagher sgallagh@redhat.com wrote:
I've updated https://fedoraproject.org/wiki/Changes/NodejsRepackaging with the results of this discussion. I'll go the `nodejs-$MAJOR-unversioned-command` route.
On 15. 09. 22 19:14, Stephen Gallagher wrote:
As I'm implementing this, I'm realizing that it probably only makes sense to have the default version of Node.js on each Fedora release provide the unversioned-command. Otherwise it becomes really hard to ensure that the RPM macros like %{nodejs_sitelib} refer to the correct location. So I think I'll stick with "if you're packaging for Fedora, it has to work on the default Node release *or* you must deal with everything yourself if you need to run on a different runtime".
+1
On Fri, Sep 16, 2022 at 1:14 AM Stephen Gallagher sgallagh@redhat.com wrote:
As I'm implementing this, I'm realizing that it probably only makes sense to have the default version of Node.js on each Fedora release provide the unversioned-command. Otherwise it becomes really hard to ensure that the RPM macros like %{nodejs_sitelib} refer to the correct location. So I think I'll stick with "if you're packaging for Fedora, it has to work on the default Node release *or* you must deal with everything yourself if you need to run on a different runtime".
Sounds reasonable (as a non-nodejs user:)
For our Haskell ghc, the new ghcX.Y packages introduced since F36 have given a big improvement in flexibility in my opinion. The main Fedora ghc package provides /usr/bin/ghc by default, though the ghcX.Y packages do have an optional unversioned subpackage for it that conflicts with ghc. So users are normally expected just to use the default version or specify the wanted version, unless they really want to default to a newer (or older in the future) one instead.
Jens
On Wed, Sep 21, 2022 at 7:00 AM Jens-Ulrik Petersen petersen@redhat.com wrote:
On Fri, Sep 16, 2022 at 1:14 AM Stephen Gallagher sgallagh@redhat.com wrote:
As I'm implementing this, I'm realizing that it probably only makes sense to have the default version of Node.js on each Fedora release provide the unversioned-command. Otherwise it becomes really hard to ensure that the RPM macros like %{nodejs_sitelib} refer to the correct location. So I think I'll stick with "if you're packaging for Fedora, it has to work on the default Node release *or* you must deal with everything yourself if you need to run on a different runtime".
Sounds reasonable (as a non-nodejs user:)
For our Haskell ghc, the new ghcX.Y packages introduced since F36 have given a big improvement in flexibility in my opinion. The main Fedora ghc package provides /usr/bin/ghc by default, though the ghcX.Y packages do have an optional unversioned subpackage for it that conflicts with ghc. So users are normally expected just to use the default version or specify the wanted version, unless they really want to default to a newer (or older in the future) one instead.
OK, I just took a look at how Haskell is doing this. I may take a cue from ghc-deps.sh and implement a similar approach. Thanks for the idea!
Dne 07. 09. 22 v 19:30 Neal Gompa napsal(a):
The openSUSE folks wrote an alternative alternatives implementation called libalternatives that is likely to be rpm-ostree compatible. It works differently from regular alternatives, and I've got a package in copr for it[1].
It might be worth exploring for this...
Oh, this is wonderful. I have always dreamed about this (and something more [2]). At least since we introduced `rubypick` into Fedora [3].
Vít
[2] https://github.com/openSUSE/libalternatives/issues/21
[3] https://github.com/fedora-ruby/rubypick
That said, I don't think alternatives makes sense for this case.
-- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
Dne 06. 09. 22 v 20:28 Ben Cotton napsal(a):
https://fedoraproject.org/wiki/Changes/NodejsRepackaging
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 == We are reworking the Node.js packaging to make Node.js versions available as parallel-installable packages.
== Owner ==
- Name: [[User:SGallagh| Stephen Gallagher]]
- Email: sgallagh@redhat.com
== 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`. We will also take advantage of the `alternatives` subsystem to populate `/usr/bin/node` from the default Node.js version for that release, or if the default is not installed, the highest currently-installed version.
Notes:
- The default in Fedora 38 will be Node.js 18. If a user was to
install Node.js 16 and Node.js 20, but not Node.js 18, then Node.js 20 would provide `/usr/bin/node`
- The policy going forward will be to have the most recently-released
version of Node.js at the time of Fedora's expected Beta release date be the default for that release throughout its lifetime.
Is there going to be `nodejs` nonversioned package? I hope it will. The version numbers are annoying.
Also, it seems that you assume that nodejs- packages will work just fine with different versions of Node.js, then what is the point of having multiple versions of Node.js around? Why not have just latest?
Vít
On Wed, 7 Sept 2022 at 12:55, Vít Ondruch vondruch@redhat.com wrote:
Dne 06. 09. 22 v 20:28 Ben Cotton napsal(a):
https://fedoraproject.org/wiki/Changes/NodejsRepackaging
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 == We are reworking the Node.js packaging to make Node.js versions available as parallel-installable packages.
== Owner ==
- Name: [[User:SGallagh| Stephen Gallagher]]
- Email: sgallagh@redhat.com
== 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`. We will also take advantage of the `alternatives` subsystem to populate `/usr/bin/node` from the default Node.js version for that release, or if the default is not installed, the highest currently-installed version.
Notes:
- The default in Fedora 38 will be Node.js 18. If a user was to
install Node.js 16 and Node.js 20, but not Node.js 18, then Node.js 20 would provide `/usr/bin/node`
- The policy going forward will be to have the most recently-released
version of Node.js at the time of Fedora's expected Beta release date be the default for that release throughout its lifetime.
Is there going to be `nodejs` nonversioned package? I hope it will. The version numbers are annoying.
Going from the various "why has node blown up" threads in the past is that trying has failed multiple times. Too many API changes and other items saying they worked before but do not afterwards.
Also, it seems that you assume that nodejs- packages will work just fine with different versions of Node.js, then what is the point of having multiple versions of Node.js around? Why not have just latest?
Vít
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
On Tue, Sep 6, 2022 at 2:29 PM Ben Cotton bcotton@redhat.com wrote:
https://fedoraproject.org/wiki/Changes/NodejsRepackaging
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 == We are reworking the Node.js packaging to make Node.js versions available as parallel-installable packages.
So, I'd like to give an update here and address potential issues that I discovered this week surrounding the upgrade path.
First and most exciting: I've got the packaging work for Node.js 16 and Node.js 18 in good shape and it can be tried out by using my COPR at https://copr.fedorainfracloud.org/coprs/sgallagh/nodejs-alternatives/ (`dnf copr enable sgallagh/nodejs-alternatives`) on x86_64 systems. Thanks to the input of folks on this thread, I've now put together parallel-installable versions, any of which can provide the /usr/bin/node by installing the appropriate `nodejsXX-interpreter-default` package. I've also got the dependencies established in such a way that a fresh install of `dnf install nodejs` on releases will result in automatically installing the latest stable version that was available at the Fedora release's Beta Freeze. (So for F38 it will be Node.js 18, for F39 it will be Node.js 20).
On upgrade from Fedora 37 (which has nodejs == 18.x) to Fedora 38, the nodejs18 package will Obsolete the nodejs package. On upgrade of the same system to Fedora 39 later, it will continue on the Node.js 18 package. To switch to the newer version, the user will need to manually run `dnf swap nodejs18-interpreter-default nodejs20-interpreter-default). While this may seem unexpected behavior, I feel that it's better to maintain compatibility on upgrade with any applications in use rather than to force the upgrade unless the current version is going out of support.
When a Node.js release goes out of support, we have a question to answer: do we Obsolete it with a newer version? If so, which one? The most recent version or the oldest one? It will not be 100% compatible in either case. Do we Obsolete it with fedora-retired-packages? Do we just leave the packages in Fedora forever (possibly patching the `/usr/bin/node` binary to warn that it's out of support)?
There's another potential upgrade issue: We have multiple choices of how to upgrade from the nodejs package to the nodejsXX packages: 1) Upgrading from either F36 or F37 will result in you getting Node.js 18. (This method is closest to how things worked prior to this Change, where the nodejs package would just get updated to the latest stable release) 2) Upgrading from F36 will move you onto nodejs16 in F38. Upgrading from F37 will move you onto Node.js 18 in F38. (This method maintains compatibility with applications running on the current system) 3) Upgrading from F36 or F37 will *remove* the nodejs package and the user will need to manually select one to install. (This method has increased friction, but more user choice) 4) Upgrading from F36 or F37 will leave the existing nodejs package on the system, receiving no updates. Users of F38 will need to manually remove and install a newer version. (This method is high-friction, offers nothing over any of the others and potentially leaves people vulnerable)
With options 1), 3) and 4), we can make the change in F38 exclusively. However if we want to do 2), we *also* need to either backport this Change to Fedora 37 and Fedora 36 because otherwise we would have to continuously update the Obsoletes: values in F38. With 1) I can update the Obsoletes: to just treat any Node.js with an epoch < 3 as the trigger to move to nodejs18.
My questions to those brave souls who have read this far: 1) Which do you think is the best of the above options for upgrades to F38? 2) What do we do about future upgrades in the following scenarios: a. The user has nodejsXX installed as the default interpreter. The nodejsXX package is no longer available upon upgrade (EOL). b. The user has nodejsXX installed as the default interpreter. The nodejsXX package is available but non-default upon upgrade.
Thank you for reading to the end.
Hi Stephen,
Stephen Gallagher sgallagh@redhat.com writes:
On Tue, Sep 6, 2022 at 2:29 PM Ben Cotton bcotton@redhat.com wrote:
*snip*
When a Node.js release goes out of support, we have a question to answer: do we Obsolete it with a newer version? If so, which one? The most recent version or the oldest one? It will not be 100% compatible in either case. Do we Obsolete it with fedora-retired-packages? Do we just leave the packages in Fedora forever (possibly patching the `/usr/bin/node` binary to warn that it's out of support)?
I would definitely obsolete it. I personally would obsolete it with the default nodejs version, if there is one.
There's another potential upgrade issue: We have multiple choices of how to upgrade from the nodejs package to the nodejsXX packages:
- Upgrading from either F36 or F37 will result in you getting Node.js
- (This method is closest to how things worked prior to this Change,
where the nodejs package would just get updated to the latest stable release) 2) Upgrading from F36 will move you onto nodejs16 in F38. Upgrading from F37 will move you onto Node.js 18 in F38. (This method maintains compatibility with applications running on the current system) 3) Upgrading from F36 or F37 will *remove* the nodejs package and the user will need to manually select one to install. (This method has increased friction, but more user choice) 4) Upgrading from F36 or F37 will leave the existing nodejs package on the system, receiving no updates. Users of F38 will need to manually remove and install a newer version. (This method is high-friction, offers nothing over any of the others and potentially leaves people vulnerable)
With options 1), 3) and 4), we can make the change in F38 exclusively. However if we want to do 2), we *also* need to either backport this Change to Fedora 37 and Fedora 36 because otherwise we would have to continuously update the Obsoletes: values in F38. With 1) I can update the Obsoletes: to just treat any Node.js with an epoch < 3 as the trigger to move to nodejs18.
My questions to those brave souls who have read this far:
- Which do you think is the best of the above options for upgrades to F38?
My personal preference would be Option 1. Imho it's a bit expected that you might have to do some cleanup after a system upgrade. So moving to the latest stable version sounds like a good overall compromise for most users: you'll get the latest stable version and if you need an older version, you'll (hopefully) figure it out during the post-upgrade cleanup. (And we could implement it without backporting)
- What do we do about future upgrades in the following scenarios: a. The user has nodejsXX installed as the default interpreter. The
nodejsXX package is no longer available upon upgrade (EOL).
I would upgrade to the new default version.
b. The user has nodejsXX installed as the default interpreter. ThenodejsXX package is available but non-default upon upgrade.
Unless it is very simple to upgrade to that non-default version on upgrade, I'd just upgrade to the new default/latest stable as well in this case.
Cheers,
Dan
On Sun, Oct 09, 2022 at 10:58:58PM +0200, Dan Čermák wrote:
Hi Stephen,
Stephen Gallagher sgallagh@redhat.com writes:
On Tue, Sep 6, 2022 at 2:29 PM Ben Cotton bcotton@redhat.com wrote:
*snip*
When a Node.js release goes out of support, we have a question to answer: do we Obsolete it with a newer version? If so, which one? The most recent version or the oldest one? It will not be 100% compatible in either case. Do we Obsolete it with fedora-retired-packages? Do we just leave the packages in Fedora forever (possibly patching the `/usr/bin/node` binary to warn that it's out of support)?
I would definitely obsolete it. I personally would obsolete it with the default nodejs version, if there is one.
There's another potential upgrade issue: We have multiple choices of how to upgrade from the nodejs package to the nodejsXX packages:
- Upgrading from either F36 or F37 will result in you getting Node.js
- (This method is closest to how things worked prior to this Change,
where the nodejs package would just get updated to the latest stable release) 2) Upgrading from F36 will move you onto nodejs16 in F38. Upgrading from F37 will move you onto Node.js 18 in F38. (This method maintains compatibility with applications running on the current system) 3) Upgrading from F36 or F37 will *remove* the nodejs package and the user will need to manually select one to install. (This method has increased friction, but more user choice) 4) Upgrading from F36 or F37 will leave the existing nodejs package on the system, receiving no updates. Users of F38 will need to manually remove and install a newer version. (This method is high-friction, offers nothing over any of the others and potentially leaves people vulnerable)
With options 1), 3) and 4), we can make the change in F38 exclusively. However if we want to do 2), we *also* need to either backport this Change to Fedora 37 and Fedora 36 because otherwise we would have to continuously update the Obsoletes: values in F38. With 1) I can update the Obsoletes: to just treat any Node.js with an epoch < 3 as the trigger to move to nodejs18.
My questions to those brave souls who have read this far:
- Which do you think is the best of the above options for upgrades to F38?
My personal preference would be Option 1. Imho it's a bit expected that you might have to do some cleanup after a system upgrade. So moving to the latest stable version sounds like a good overall compromise for most users: you'll get the latest stable version and if you need an older version, you'll (hopefully) figure it out during the post-upgrade cleanup. (And we could implement it without backporting)
+1. It also sounds like this option is easiest on the maintainers.
Zbyszek
- What do we do about future upgrades in the following scenarios: a. The user has nodejsXX installed as the default interpreter. The
nodejsXX package is no longer available upon upgrade (EOL).
I would upgrade to the new default version.
b. The user has nodejsXX installed as the default interpreter. ThenodejsXX package is available but non-default upon upgrade.
Unless it is very simple to upgrade to that non-default version on upgrade, I'd just upgrade to the new default/latest stable as well in this case.
Mon, Oct 10, 2022 at 9:04 AM Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:
On Sun, Oct 09, 2022 at 10:58:58PM +0200, Dan Čermák wrote:
There's another potential upgrade issue: We have multiple choices of how to upgrade from the nodejs package to the nodejsXX packages:
- Upgrading from either F36 or F37 will result in you getting Node.js
- (This method is closest to how things worked prior to this Change,
where the nodejs package would just get updated to the latest stable release)
(snip)
My personal preference would be Option 1. Imho it's a bit expected that you might have to do some cleanup after a system upgrade. So moving to the latest stable version sounds like a good overall compromise for most users: you'll get the latest stable version and if you need an older version, you'll (hopefully) figure it out during the post-upgrade cleanup. (And we could implement it without backporting)
+1. It also sounds like this option is easiest on the maintainers.
I agree. I think there's at least general consensus around the idea that a system upgraded from Fedora X to Fedora X+1 should be as close as possible as a fresh install of Fedora X+1. The versioned Python packages already work like that, and it works pretty well in my experience. Additionally, this works around the problem of "what happens when users keep upgrading their Fedora install for a few releases" - otherwise they might get stuck with ancient nodejs versions. I'd rather not repeat the "OpenJDK 11 -> 17" upgrade problems, where some of my systems were stuck with OpenJDK 11 instead of getting upgraded to OpenJDK 17 upon upgrade.
Fabio
I have not used nodejs for development in quite a while so cannot respond from an involved user perspective. Given that context, I concur with Dan's reasoning and choices.
On a more meta note, Fedora has at least 3 mechanisms to provide multiple versions of some component for a given release - alternatives, modules, and versioned packages (ala nodejs, haskell, etc). What is the best place to document this for a target user community (e.g. nodejs users and developers)? We are looking at adopting alternative versions for plain kubernetes in Fedora.
Best regards
Brad
On Tue, Oct 11, 2022 at 2:45 AM Fabio Valentini decathorpe@gmail.com wrote:
+1. It also sounds like this option is easiest on the maintainers.
I agree. I think there's at least general consensus around the idea
Dne 07. 10. 22 v 20:54 Stephen Gallagher napsal(a):
On Tue, Sep 6, 2022 at 2:29 PM Ben Cotton bcotton@redhat.com wrote:
https://fedoraproject.org/wiki/Changes/NodejsRepackaging
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 == We are reworking the Node.js packaging to make Node.js versions available as parallel-installable packages.
So, I'd like to give an update here and address potential issues that I discovered this week surrounding the upgrade path.
First and most exciting: I've got the packaging work for Node.js 16 and Node.js 18 in good shape and it can be tried out by using my COPR at https://copr.fedorainfracloud.org/coprs/sgallagh/nodejs-alternatives/ (`dnf copr enable sgallagh/nodejs-alternatives`) on x86_64 systems. Thanks to the input of folks on this thread, I've now put together parallel-installable versions, any of which can provide the /usr/bin/node by installing the appropriate `nodejsXX-interpreter-default` package. I've also got the dependencies established in such a way that a fresh install of `dnf install nodejs` on releases will result in automatically installing the latest stable version that was available at the Fedora release's Beta Freeze. (So for F38 it will be Node.js 18, for F39 it will be Node.js 20).
On upgrade from Fedora 37 (which has nodejs == 18.x) to Fedora 38, the nodejs18 package will Obsolete the nodejs package. On upgrade of the same system to Fedora 39 later, it will continue on the Node.js 18 package. To switch to the newer version, the user will need to manually run `dnf swap nodejs18-interpreter-default nodejs20-interpreter-default). While this may seem unexpected behavior, I feel that it's better to maintain compatibility on upgrade with any applications in use rather than to force the upgrade unless the current version is going out of support.
When a Node.js release goes out of support, we have a question to answer: do we Obsolete it with a newer version? If so, which one? The most recent version or the oldest one? It will not be 100% compatible in either case. Do we Obsolete it with fedora-retired-packages? Do we just leave the packages in Fedora forever (possibly patching the `/usr/bin/node` binary to warn that it's out of support)?
If you kept nonversioned rolling nodejs package, which would be the default, you would not have the issues with upgrade. And if somebody installed the versioned package, then it would be up to the user to take action.
I would strongly suggest against introducing the versioned packages. It never made anything good for Fedora. If you want to keep providing some version for backward compatibility, so be it, add the versioned package. But don't do that by default.
Vít
There's another potential upgrade issue: We have multiple choices of how to upgrade from the nodejs package to the nodejsXX packages:
- Upgrading from either F36 or F37 will result in you getting Node.js
- (This method is closest to how things worked prior to this Change,
where the nodejs package would just get updated to the latest stable release) 2) Upgrading from F36 will move you onto nodejs16 in F38. Upgrading from F37 will move you onto Node.js 18 in F38. (This method maintains compatibility with applications running on the current system) 3) Upgrading from F36 or F37 will *remove* the nodejs package and the user will need to manually select one to install. (This method has increased friction, but more user choice) 4) Upgrading from F36 or F37 will leave the existing nodejs package on the system, receiving no updates. Users of F38 will need to manually remove and install a newer version. (This method is high-friction, offers nothing over any of the others and potentially leaves people vulnerable)
With options 1), 3) and 4), we can make the change in F38 exclusively. However if we want to do 2), we *also* need to either backport this Change to Fedora 37 and Fedora 36 because otherwise we would have to continuously update the Obsoletes: values in F38. With 1) I can update the Obsoletes: to just treat any Node.js with an epoch < 3 as the trigger to move to nodejs18.
My questions to those brave souls who have read this far:
- Which do you think is the best of the above options for upgrades to F38?
- What do we do about future upgrades in the following scenarios: a. The user has nodejsXX installed as the default interpreter. The
nodejsXX package is no longer available upon upgrade (EOL). b. The user has nodejsXX installed as the default interpreter. The nodejsXX package is available but non-default upon upgrade.
Thank you for reading to the end. _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
I have now submitted https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2150093 and https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2150094 for the `nodejs16` and `nodejs18` packages for Fedora.
You can test them with `dnf copr enable sgallagh/nodejs-alternatives`.
The final approach I took is one that follows the example of Python3. The SRPM is versioned according to the major release number and the output binary RPMs will be `nodejs[-*]` if it is the default version for that release or `nodejs$MAJOR[-*]` if not.
I've tested the upgrade path from F36 and F37 and it appears to work fine (and could, in fact, trivially be backported to the live releases to simplify maintenance).
I'd appreciate package reviews from anyone with the available time. Thank you.
On Thu, Dec 1, 2022 at 3:16 PM Stephen Gallagher sgallagh@redhat.com wrote:
I have now submitted https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2150093 and https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2150094 for the `nodejs16` and `nodejs18` packages for Fedora.
You can test them with `dnf copr enable sgallagh/nodejs-alternatives`.
The final approach I took is one that follows the example of Python3. The SRPM is versioned according to the major release number and the output binary RPMs will be `nodejs[-*]` if it is the default version for that release or `nodejs$MAJOR[-*]` if not.
I've tested the upgrade path from F36 and F37 and it appears to work fine (and could, in fact, trivially be backported to the live releases to simplify maintenance).
I'd appreciate package reviews from anyone with the available time. Thank you.
Ping.
I still need someone to perform these reviews.
On Mon, Dec 12, 2022 at 9:20 PM Stephen Gallagher sgallagh@redhat.com wrote:
On Thu, Dec 1, 2022 at 3:16 PM Stephen Gallagher sgallagh@redhat.com wrote:
I have now submitted https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2150093 and https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2150094 for the `nodejs16` and `nodejs18` packages for Fedora.
You can test them with `dnf copr enable sgallagh/nodejs-alternatives`.
The final approach I took is one that follows the example of Python3. The SRPM is versioned according to the major release number and the output binary RPMs will be `nodejs[-*]` if it is the default version for that release or `nodejs$MAJOR[-*]` if not.
I've tested the upgrade path from F36 and F37 and it appears to work fine (and could, in fact, trivially be backported to the live releases to simplify maintenance).
I'd appreciate package reviews from anyone with the available time. Thank you.
Ping.
I still need someone to perform these reviews.
Technically, it's not a "need", but a "nice to have", since they're alternative versions of a package that already exists: https://docs.fedoraproject.org/en-US/packaging-guidelines/ReviewGuidelines/#... (bullet point 2).
So unless you really want a second opinion, you could just skip the reviews.
Fabio
On Mon, Dec 12, 2022 at 3:35 PM Fabio Valentini decathorpe@gmail.com wrote:
On Mon, Dec 12, 2022 at 9:20 PM Stephen Gallagher sgallagh@redhat.com wrote:
On Thu, Dec 1, 2022 at 3:16 PM Stephen Gallagher sgallagh@redhat.com wrote:
I have now submitted https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2150093 and https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2150094 for the `nodejs16` and `nodejs18` packages for Fedora.
You can test them with `dnf copr enable sgallagh/nodejs-alternatives`.
The final approach I took is one that follows the example of Python3. The SRPM is versioned according to the major release number and the output binary RPMs will be `nodejs[-*]` if it is the default version for that release or `nodejs$MAJOR[-*]` if not.
I've tested the upgrade path from F36 and F37 and it appears to work fine (and could, in fact, trivially be backported to the live releases to simplify maintenance).
I'd appreciate package reviews from anyone with the available time. Thank you.
Ping.
I still need someone to perform these reviews.
Technically, it's not a "need", but a "nice to have", since they're alternative versions of a package that already exists: https://docs.fedoraproject.org/en-US/packaging-guidelines/ReviewGuidelines/#... (bullet point 2).
So unless you really want a second opinion, you could just skip the reviews.
Huh... I thought I remembered we had that policy and I went looking for it, but couldn't find it. I must have skimmed over it.
Thanks
-
Ben Cotton -
Brad Smith -
Dan Čermák -
Ewoud Kohl van Wijngaarden -
Fabio Valentini -
Florian Weimer -
Jens-Ulrik Petersen -
Miro Hrončok -
Neal Gompa -
Stephen Gallagher -
Stephen Smoogen -
Vitaly Zaitsev -
Vít Ondruch -
Zbigniew Jędrzejewski-Szmek