On Wed, Sep 7, 2022 at 1:32 PM Neal Gompa <ngompa13(a)gmail.com> wrote:
On Wed, Sep 7, 2022 at 12:45 PM Stephen Gallagher <sgallagh(a)redhat.com> wrote:
> On Wed, Sep 7, 2022 at 9:03 AM Neal Gompa <ngompa13(a)gmail.com> wrote:
> > On Wed, Sep 7, 2022 at 2:49 AM Vitaly Zaitsev via devel
> > <devel(a)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
> > > > Node.js version for that release, or if the default is not
> > >
> > > 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
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.
On both my Silverblue main system and Fedora IoT RPi system,
/var/lib/alternatives is actually a symlink to
I think that means that the alternatives system "works" but the user
cannot change it. Maybe we can ask for that to move to
It might be worth exploring for this...
That said, I don't think alternatives makes sense for this case.
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> wrote:
And 3 more for "stick with whatever ships with the version of node they're
On Wed, Sep 7, 2022 at 11:18 AM Michael Dawson <midawson(a)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(a)gmail.com> wrote:
>> On Wed, Sep 7, 2022 at 9:47 AM Michael Dawson <midawson(a)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
>> 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
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
b. Do we allow users to mix-and-match the npm default independently