F38 proposal: Node.js Repackaging (Self-Contained Change proposal)

[Ben Cotton]

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(a)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/[e-mail]....
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/[e-mail]....

== Release Notes ==
Multiple releases of Node.js may now be installed in parallel from the
Fedora repositories.


-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis

[Ewoud Kohl van Wijngaarden]

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.

[Stephen Gallagher]

On Tue, Sep 6, 2022 at 7:07 PM Ewoud Kohl van Wijngaarden
<ewoud+fedora(a)kohlvanwijngaarden.nl&gt; 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.

[Ewoud Kohl van Wijngaarden]

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(a)kohlvanwijngaarden.nl&gt; 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.

[Stephen Gallagher]

On Wed, Sep 7, 2022 at 1:36 PM Ewoud Kohl van Wijngaarden
<ewoud+fedora(a)kohlvanwijngaarden.nl&gt; 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_...


>  >> 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(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

[Florian Weimer]

* Stephen Gallagher:

>  On Wed, Sep 7, 2022 at 1:36 PM Ewoud Kohl van Wijngaarden
>  <ewoud+fedora(a)kohlvanwijngaarden.nl&gt; 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

[Vitaly Zaitsev]

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.

-- 
Sincerely,
   Vitaly Zaitsev (vitaly(a)easycoding.org)

[Neal Gompa]

On Wed, Sep 7, 2022 at 2:49 AM Vitaly Zaitsev via devel
<devel(a)lists.fedoraproject.org&gt; 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.



-- 
真実はいつも一つ！/ Always, there's only one truth!

[Stephen Gallagher]

On Wed, Sep 7, 2022 at 9:03 AM Neal Gompa <ngompa13(a)gmail.com&gt; wrote:
>  On Wed, Sep 7, 2022 at 2:49 AM Vitaly Zaitsev via devel
>  <devel(a)lists.fedoraproject.org&gt; 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`.

[Neal Gompa]

On Wed, Sep 7, 2022 at 12:45 PM Stephen Gallagher <sgallagh(a)redhat.com&gt; wrote:
>  On Wed, Sep 7, 2022 at 9:03 AM Neal Gompa <ngompa13(a)gmail.com&gt; wrote:
>  >
>  > On Wed, Sep 7, 2022 at 2:49 AM Vitaly Zaitsev via devel
>  > <devel(a)lists.fedoraproject.org&gt; 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!

[Stephen Gallagher]

On Wed, Sep 7, 2022 at 1:32 PM Neal Gompa <ngompa13(a)gmail.com&gt; wrote:
>  On Wed, Sep 7, 2022 at 12:45 PM Stephen Gallagher <sgallagh(a)redhat.com&gt; wrote:
>  >
>  > On Wed, Sep 7, 2022 at 9:03 AM Neal Gompa <ngompa13(a)gmail.com&gt; wrote:
>  > >
>  > > On Wed, Sep 7, 2022 at 2:49 AM Vitaly Zaitsev via devel
>  > > <devel(a)lists.fedoraproject.org&gt; 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.
>
>  [1]: https://copr.fedorainfracloud.org/coprs/ngompa/alts/build/4815991/ 



Moving this conversation from nodejs(a)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(a)redhat.com&gt; 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(a)redhat.com&gt; 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(a)gmail.com&gt; wrote:
> >>
> >> On Wed, Sep 7, 2022 at 9:47 AM Michael Dawson <midawson(a)redhat.com&gt; 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?

[Neal Gompa]

On Wed, Sep 7, 2022 at 1:41 PM Stephen Gallagher <sgallagh(a)redhat.com&gt; wrote:
>  On Wed, Sep 7, 2022 at 1:32 PM Neal Gompa <ngompa13(a)gmail.com&gt; wrote:
>  >
>  > On Wed, Sep 7, 2022 at 12:45 PM Stephen Gallagher <sgallagh(a)redhat.com&gt;
> wrote:
>  > >
>  > > On Wed, Sep 7, 2022 at 9:03 AM Neal Gompa <ngompa13(a)gmail.com&gt; wrote:
>  > > >
>  > > > On Wed, Sep 7, 2022 at 2:49 AM Vitaly Zaitsev via devel
>  > > > <devel(a)lists.fedoraproject.org&gt; 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.
>  >
>  > [1]: https://copr.fedorainfracloud.org/coprs/ngompa/alts/build/4815991/
>
>
>
>
>  Moving this conversation from nodejs(a)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(a)redhat.com&gt; 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(a)redhat.com&gt; 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(a)gmail.com&gt; wrote:
>  >>>
>  >>> On Wed, Sep 7, 2022 at 9:47 AM Michael Dawson <midawson(a)redhat.com&gt;
> 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? 
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?



-- 
真実はいつも一つ！/ Always, there's only one truth!

[Stephen Gallagher]

On Wed, Sep 7, 2022 at 1:56 PM Neal Gompa <ngompa13(a)gmail.com&gt; wrote:
>  On Wed, Sep 7, 2022 at 1:41 PM Stephen Gallagher <sgallagh(a)redhat.com&gt; wrote:
>  >
>  > On Wed, Sep 7, 2022 at 1:32 PM Neal Gompa <ngompa13(a)gmail.com&gt; wrote:
>  > >
>  > > On Wed, Sep 7, 2022 at 12:45 PM Stephen Gallagher <sgallagh(a)redhat.com&gt;
> wrote:
>  > > >
>  > > > On Wed, Sep 7, 2022 at 9:03 AM Neal Gompa <ngompa13(a)gmail.com&gt;
> wrote:
>  > > > >
>  > > > > On Wed, Sep 7, 2022 at 2:49 AM Vitaly Zaitsev via devel
>  > > > > <devel(a)lists.fedoraproject.org&gt; 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.
>  > >
>  > > [1]: https://copr.fedorainfracloud.org/coprs/ngompa/alts/build/4815991/
>  >
>  >
>  >
>  >
>  > Moving this conversation from nodejs(a)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(a)redhat.com&gt; 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(a)redhat.com&gt;
> 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(a)gmail.com&gt;
> wrote:
>  > >>>
>  > >>> On Wed, Sep 7, 2022 at 9:47 AM Michael Dawson
> <midawson(a)redhat.com&gt; 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?
>
>  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.

[Vít Ondruch]

Dne 07. 09. 22 v 19:41 Stephen Gallagher napsal(a):
>  On Wed, Sep 7, 2022 at 1:32 PM Neal Gompa <ngompa13(a)gmail.com&gt;
> wrote:
> > On Wed, Sep 7, 2022 at 12:45 PM Stephen Gallagher <sgallagh(a)redhat.com&gt;
> wrote:
> >> On Wed, Sep 7, 2022 at 9:03 AM Neal Gompa <ngompa13(a)gmail.com&gt; wrote:
> >>> On Wed, Sep 7, 2022 at 2:49 AM Vitaly Zaitsev via devel
> >>> <devel(a)lists.fedoraproject.org&gt; 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.
> >
> > [1]: https://copr.fedorainfracloud.org/coprs/ngompa/alts/build/4815991/
>
>
>
>  Moving this conversation from nodejs(a)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(a)redhat.com&gt; 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(a)redhat.com&gt; 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(a)gmail.com&gt; wrote:
> >>> On Wed, Sep 7, 2022 at 9:47 AM Michael Dawson <midawson(a)redhat.com&gt;
> 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/c2026da1750e6d0cc70c7370a084...


>    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?
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
>

[Miro Hrončok]

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.

-- 
Miro Hrončok
-- 
Phone: [phone]
IRC: mhroncok

[Stephen Gallagher]

On Wed, Sep 7, 2022 at 3:30 PM Miro Hrončok <mhroncok(a)redhat.com&gt; 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 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. 

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.

[Miro Hrončok]

On 12. 09. 22 20:56, Stephen Gallagher wrote:
>  On Wed, Sep 7, 2022 at 3:30 PM Miro Hrončok
> <mhroncok(a)redhat.com&gt; 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 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.
>  
>  
>  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.

-- 
Miro Hrončok
-- 
Phone: [phone]
IRC: mhroncok

[Stephen Gallagher]

On Mon, Sep 12, 2022 at 3:34 PM Miro Hrončok <mhroncok(a)redhat.com&gt; 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.

[Stephen Gallagher]

I've updated https://fedoraproject.org/wiki/Changes/NodejsRepackaging
with the results of this discussion. I'll go the
`nodejs-$MAJOR-unversioned-command` route.

[Stephen Gallagher]

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(a)redhat.com&gt; 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.

[Miro Hrončok]

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

-- 
Miro Hrončok
-- 
Phone: [phone]
IRC: mhroncok

[Jens-Ulrik Petersen]

On Fri, Sep 16, 2022 at 1:14 AM Stephen Gallagher <sgallagh(a)redhat.com&gt;
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

[Stephen Gallagher]

On Wed, Sep 21, 2022 at 7:00 AM Jens-Ulrik Petersen <petersen(a)redhat.com&gt; wrote:
>  On Fri, Sep 16, 2022 at 1:14 AM Stephen Gallagher <sgallagh(a)redhat.com&gt; 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!

[Vít Ondruch]

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.
>
>  [1]: https://copr.fedorainfracloud.org/coprs/ngompa/alts/build/4815991/
>
>
>
>
>  --
>  真実はいつも一つ！/ Always, there's only one truth!
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
>

[Vít Ondruch]

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(a)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

[Stephen Smoogen]

On Wed, 7 Sept 2022 at 12:55, Vít Ondruch <vondruch(a)redhat.com&gt; 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(a)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(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  Do not reply to spam, report it:
>  https://pagure.io/fedora-infrastructure/new_issue
>  

-- 
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren

[INPUT REQUESTED] Re: F38 proposal: Node.js Repackaging (Self-Contained Change proposal)

[Stephen Gallagher]

On Tue, Sep 6, 2022 at 2:29 PM Ben Cotton <bcotton(a)redhat.com&gt; 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.

[INPUT REQUESTED] Re: F38 proposal: Node.js Repackaging (Self-Contained Change proposal)

[Dan Čermák]

Hi Stephen,

Stephen Gallagher <sgallagh(a)redhat.com&gt; writes:

>  On Tue, Sep 6, 2022 at 2:29 PM Ben Cotton <bcotton(a)redhat.com&gt;
> 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:
>  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? 
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)

>  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). 
I would upgrade to the new default version.

>      b. The user has nodejsXX installed as the default interpreter.
> The
>  nodejsXX 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

[INPUT REQUESTED] Re: F38 proposal: Node.js Repackaging (Self-Contained Change proposal)

[Zbigniew Jędrzejewski-Szmek]

On Sun, Oct 09, 2022 at 10:58:58PM +0200, Dan Čermák wrote:
>  Hi Stephen,
>  
>  Stephen Gallagher <sgallagh(a)redhat.com&gt; writes:
>  
>  > On Tue, Sep 6, 2022 at 2:29 PM Ben Cotton <bcotton(a)redhat.com&gt; 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:
>  > 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?
>  
>  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

> > 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).
> 
> I would upgrade to the new default version.
> 
> >     b. The user has nodejsXX installed as the default interpreter. The
> > nodejsXX 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.

[INPUT REQUESTED] Re: F38 proposal: Node.js Repackaging (Self-Contained Change proposal)

[Fabio Valentini]

Mon, Oct 10, 2022 at 9:04 AM Zbigniew Jędrzejewski-Szmek
<zbyszek(a)in.waw.pl&gt; 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:
>  > > 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) 
(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

[INPUT REQUESTED] Re: F38 proposal: Node.js Repackaging (Self-Contained Change proposal)

[Brad Smith]

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(a)gmail.com&gt; 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
>

[INPUT REQUESTED] Re: F38 proposal: Node.js Repackaging (Self-Contained Change proposal)

[Vít Ondruch]

Dne 07. 10. 22 v 20:54 Stephen Gallagher napsal(a):
>  On Tue, Sep 6, 2022 at 2:29 PM Ben Cotton <bcotton(a)redhat.com&gt;
> 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:
>  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.
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
>

[INPUT REQUESTED] Re: F38 proposal: Node.js Repackaging (Self-Contained Change proposal)

[Stephen Gallagher]

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.

[INPUT REQUESTED] Re: F38 proposal: Node.js Repackaging (Self-Contained Change proposal)

[Stephen Gallagher]

On Thu, Dec 1, 2022 at 3:16 PM Stephen Gallagher <sgallagh(a)redhat.com&gt; 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.

[INPUT REQUESTED] Re: F38 proposal: Node.js Repackaging (Self-Contained Change proposal)

[Fabio Valentini]

On Mon, Dec 12, 2022 at 9:20 PM Stephen Gallagher <sgallagh(a)redhat.com&gt; wrote:
>  On Thu, Dec 1, 2022 at 3:16 PM Stephen Gallagher <sgallagh(a)redhat.com&gt; 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/ReviewGuideline...
(bullet point 2).

So unless you really want a second opinion, you could just skip the reviews.

Fabio

[INPUT REQUESTED] Re: F38 proposal: Node.js Repackaging (Self-Contained Change proposal)

[Stephen Gallagher]

On Mon, Dec 12, 2022 at 3:35 PM Fabio Valentini <decathorpe(a)gmail.com&gt; wrote:
>  On Mon, Dec 12, 2022 at 9:20 PM Stephen Gallagher <sgallagh(a)redhat.com&gt; wrote:
>  >
>  > On Thu, Dec 1, 2022 at 3:16 PM Stephen Gallagher <sgallagh(a)redhat.com&gt; 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/ReviewGuideline...
>  (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