Node.js Metapackage Testing & Feedback

[Andrei Radchenko]

Hi folks,

NodejsMetapackages
https://fedoraproject.org/wiki/Changes/NodeJSMetapackages#Scope change is
finally ready to test!

Here is the COPR
https://copr.fedorainfracloud.org/coprs/jstanek/nodejs-metapackage/ where
you can get it, play with it, kindly report back your findings or bugs.

For the sake of testing, we set 'default' a.k.a. 'rolling stream' (term is
not yet set) as nodejs24,  in order to test upgrade: `dnf install nodejs`
will give you nodejs24 binary.

Looking forward to your feedback!
Cheers,
Andrei from Node.js team.

[Maxwell G]

9 Jun 2026 4:46:54 am Andrei Radchenko :
> Hi folks,
>
> NodejsMetapackages[https://fedoraproject.org/wiki/Changes/NodeJSMetapackages#Scope%5D%C2%A0chan... 
> is finally ready to test!
>
> Here is the 
> COPR[https://copr.fedorainfracloud.org/coprs/jstanek/nodejs-metapackage/] 
> where you can get it, play with it, kindly report back your findings or 
> bugs.
>
> For the sake of testing, we set 'default' a.k.a. 'rolling stream' (term 
> is not yet set) as nodejs24,  in order to test upgrade: `dnf install 
> nodejs` will give you nodejs24 binary.
>
> Looking forward to your feedback!
> Cheers,
> Andrei from Node.js team.

Hi Andrei,

Thank you for working on this! For the unversioned metapackages, may I 
suggest only having nodejs and nodejs-npm without the separate -bin 
subpackages like we have for the versioned packages? You could then 
include the /usr/bin symlinks and relevant Provides and Conflicts 
directly in the nodejs and nodejs-npm packages. I don't think the 
separate unversioned -bin packages make sense here, since AFAIU the goal 
of the unversioned metapackages is for users to always get the primary 
version and have that be the system default.

All the best,
Maxwell

[Andrei Radchenko]

I agree it is not ideal, but one of our big goals here was to save upgrade
path, hence packaging some stuff twice. And I assume this latest
development of creating unversioned `-bin` packages has something to do
with it. DNF was giving us a lot of issues with file level conflicts etc.

I will do some builds to test our options though.

On Tue, Jun 9, 2026 at 12:48 PM Maxwell G  wrote:
> 9 Jun 2026 4:46:54 am Andrei Radchenko :
>
> Hi folks,
>
> NodejsMetapackages
> https://fedoraproject.org/wiki/Changes/NodeJSMetapackages#Scope change
> is finally ready to test!
>
> Here is the COPR
> https://copr.fedorainfracloud.org/coprs/jstanek/nodejs-metapackage/
> where you can get it, play with it, kindly report back your findings or
> bugs.
>
> For the sake of testing, we set 'default' a.k.a. 'rolling stream' (term is
> not yet set) as nodejs24,  in order to test upgrade: `dnf install nodejs`
> will give you nodejs24 binary.
>
> Looking forward to your feedback!
> Cheers,
> Andrei from Node.js team.
>
> Hi Andrei,
>
> Thank you for working on this! For the unversioned metapackages, may I
> suggest only having nodejs and nodejs-npm without the separate -bin
> subpackages like we have for the versioned packages? You could then include
> the /usr/bin symlinks and relevant Provides and Conflicts directly in the
> nodejs and nodejs-npm packages. I don't think the separate unversioned -bin
> packages make sense here, since AFAIU the goal of the unversioned
> metapackages is for users to always get the primary version and have that
> be the system default.
>
> All the best,
> Maxwell
> --
> _______________________________________________
> devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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://forge.fedoraproject.org/infra/tickets/issues/new

[Andrei Radchenko]

Hi, Maxwell.

I did try your idea and from quick testing it seems to work, including
upgrade.
I tested with enabling sub packages is 22 and 24 then:
Forced nodejs22 meta: `dnf install nodejs-22.22.2` - gives you nodejs,
nodejs22, including binary etc;
`dnf upgrade nodejs` - upgrades to nodejs24, replacing `nodejs`,
`nodejs-npm`.

Not sure if we can make it clear out nodejs(old) stuff in the same
transaction but that's not blocking atm.
Please try it: copr

https://copr.fedorainfracloud.org/coprs/aradchen/nodejs-meta-sub-packages/
Regards,
Andrei

On Tue, Jun 9, 2026 at 12:48 PM Maxwell G  wrote:
> 9 Jun 2026 4:46:54 am Andrei Radchenko :
>
> Hi folks,
>
> NodejsMetapackages
> https://fedoraproject.org/wiki/Changes/NodeJSMetapackages#Scope change
> is finally ready to test!
>
> Here is the COPR
> https://copr.fedorainfracloud.org/coprs/jstanek/nodejs-metapackage/
> where you can get it, play with it, kindly report back your findings or
> bugs.
>
> For the sake of testing, we set 'default' a.k.a. 'rolling stream' (term is
> not yet set) as nodejs24,  in order to test upgrade: `dnf install nodejs`
> will give you nodejs24 binary.
>
> Looking forward to your feedback!
> Cheers,
> Andrei from Node.js team.
>
> Hi Andrei,
>
> Thank you for working on this! For the unversioned metapackages, may I
> suggest only having nodejs and nodejs-npm without the separate -bin
> subpackages like we have for the versioned packages? You could then include
> the /usr/bin symlinks and relevant Provides and Conflicts directly in the
> nodejs and nodejs-npm packages. I don't think the separate unversioned -bin
> packages make sense here, since AFAIU the goal of the unversioned
> metapackages is for users to always get the primary version and have that
> be the system default.
>
> All the best,
> Maxwell
> --
> _______________________________________________
> devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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://forge.fedoraproject.org/infra/tickets/issues/new

[Maxwell G]

On 6/10/26 3:28 AM, Andrei Radchenko wrote:
> Hi, Maxwell.
>
> I did try your idea and from quick testing it seems to work, including 
> upgrade.
> I tested with enabling sub packages is 22 and 24 then:
> Forced nodejs22 meta: `dnf install nodejs-22.22.2` - gives you nodejs, 
> nodejs22, including binary etc;
> `dnf upgrade nodejs` - upgrades to nodejs24, replacing `nodejs`, 
> `nodejs-npm`.

<snip>> 
https://copr.fedorainfracloud.org/coprs/aradchen/nodejs-meta-sub-packages/
> Regards,
> Andrei

Thanks for the update! I took a look at nodejs26.spec from the new Copr. 
(Side note: it might make sense to put the new specfiles in some git 
repo so it's easier to review changes.)

I think the unversioned nodejs package needs to have

```
Provides:       alternative-for(nodejs-bin) = %{node_evr}
Conflicts:      alternative-for(nodejs-bin)
```

and the unversioned nodejs-npm would need

```
Provides:       alternative-for(nodejs-npm-bin) = %{npm_evr}
Conflicts:      alternative-for(nodejs-npm-bin)
```

now that there are no unversioned -bin subpackages, since this is 
necessary to avoid file conflicts with the other nodejsNN-bin packages.

Also, I see that both nodejsNN-npm and the unversioned nodejs-npm 
Provide npm. I guess only the unversioned one should Provide npm so that 
users get the default version when running "dnf install npm."

Other than that, this looks reasonable.
> Not sure if we can make it clear out nodejs(old) stuff in the same
> transaction but that's not blocking atm.

Does dnf autoremove work here? If the only package that explicitly 
requires nodejsNN is the metapackage, I would guess that updating the 
metapackage to depend on nodejs(NN+2) would allow nodejsNN to be cleaned 
up on a user system.

Obsoletes wouldn't work here because there's no way to differentiate 
between nodejsNN installed explicitly versus nodejsNN installed by the 
metapackage.

But yeah, I think the main goal is for the metapackage to "roll" 
properly and have the /usr/bin/{node,npm} symlinks automatically get 
updated to the new node version, and the current approach does 
accomplish that AFAICS.

[Andrei Radchenko]

Hi,
> I think the unversioned nodejs package needs to have
> Provides:       alternative-for(nodejs-bin) = %{node_evr}
> Conflicts:      alternative-for(nodejs-bin)
>
> and the unversioned nodejs-npm would need
> Provides:       alternative-for(nodejs-npm-bin) = %{npm_evr}
> Conflicts:      alternative-for(nodejs-npm-bin)

I am not sure where did you look but it is already included, as for only
unversioned provides npm I will have a look, thank you!

On Wed, Jun 10, 2026 at 8:58 PM Maxwell G  wrote:
> On 6/10/26 3:28 AM, Andrei Radchenko wrote:
> > Hi, Maxwell.
> >
> > I did try your idea and from quick testing it seems to work, including
> > upgrade.
> > I tested with enabling sub packages is 22 and 24 then:
> > Forced nodejs22 meta: `dnf install nodejs-22.22.2` - gives you nodejs,
> > nodejs22, including binary etc;
> > `dnf upgrade nodejs` - upgrades to nodejs24, replacing `nodejs`,
> > `nodejs-npm`.
>
> <snip>>
> <
> https://copr.fedorainfracloud.org/coprs/aradchen/nodejs-meta-sub-packages/
> > Regards,
> > Andrei
>
> Thanks for the update! I took a look at nodejs26.spec from the new Copr.
> (Side note: it might make sense to put the new specfiles in some git
> repo so it's easier to review changes.)
>
> I think the unversioned nodejs package needs to have
> Provides:       alternative-for(nodejs-bin) = %{node_evr}
> Conflicts:      alternative-for(nodejs-bin)
>
> and the unversioned nodejs-npm would need
> Provides:       alternative-for(nodejs-npm-bin) = %{npm_evr}
> Conflicts:      alternative-for(nodejs-npm-bin)
>
> now that there are no unversioned -bin subpackages, since this is
> necessary to avoid file conflicts with the other nodejsNN-bin packages.
>
> Also, I see that both nodejsNN-npm and the unversioned nodejs-npm
> Provide npm. I guess only the unversioned one should Provide npm so that
> users get the default version when running "dnf install npm."
>
> Other than that, this looks reasonable.
> > Not sure if we can make it clear out nodejs(old) stuff in the same
> > transaction but that's not blocking atm.
>
> Does dnf autoremove work here? If the only package that explicitly
> requires nodejsNN is the metapackage, I would guess that updating the
> metapackage to depend on nodejs(NN+2) would allow nodejsNN to be cleaned
> up on a user system.
>
> Obsoletes wouldn't work here because there's no way to differentiate
> between nodejsNN installed explicitly versus nodejsNN installed by the
> metapackage.
>
> But yeah, I think the main goal is for the metapackage to "roll"
> properly and have the /usr/bin/{node,npm} symlinks automatically get
> updated to the new node version, and the current approach does
> accomplish that AFAICS.
> --
> _______________________________________________
> devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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://forge.fedoraproject.org/infra/tickets/issues/new

[Jan Stanek]

Hi there!
I was on PTO for a while, so I did not reply immediately, but I'll try
to share my view on some of the topics mentioned here now. Sorry for
the delay.
> For the unversioned metapackages, may I suggest only having nodejs and nodejs-npm without the separate -bin subpackages like we have for the versioned packages?
> I don't think the separate unversioned -bin packages make sense here, since AFAIU the goal of the unversioned metapackages is for users to always get the primary version and have that be the system default.

The "and" in the last sentence was not in the original idea. I have
always seen those two as orthogonal: You have `nodejs` installed when
you want to "roll"/"autoinstall" the distro-recommended stream, but
that doesn't say anything about which stream is `/usr/bin/node`. If
you want the symlink to also follow the recommendation, you'll have
`nodejs-bin` installed *in addition*.

Granted, I don't think many people would use it this way, so I'm
willing to not provide this option if it causes problems; but I would
not remove it just to reduce the number of generated packages.

Additionaly, there is also the matter of consistency. If we keep the
-bin packages, the rule of thumb is simple: You swap which stream is
`/usr/bin/node` by swapping the -bin package: `dnf swap --allowerasing
nodejs-bin nodejs24-bin`. If we get rid of them, it will now be "You
swap the streams by swapping the -bin packages, with the exception of
rolling stream, when you need to switch the main one": `dnf swap
--allowerasing nodejs nodejs24-bin`. For this reason alone, I'm still
in favor of keeping the packages around for the rolling stream as
well.
> Does dnf autoremove work here? If the only package that explicitly requires nodejsNN is the metapackage, I would guess that updating the metapackage to depend on nodejs(NN+2) would allow nodejsNN to be cleaned up on a user system.

That was the idea, but I have not yet personally tested it. (I should.)

WDYT?

[Maxwell G]

On 6/23/26 7:24 AM, Jan Stanek wrote:

Hi,
> Hi there!
> I was on PTO for a while, so I did not reply immediately, but I'll try
> to share my view on some of the topics mentioned here now. Sorry for
> the delay.

No problem. Thanks for chiming in!
> > For the unversioned metapackages, may I suggest only having nodejs and nodejs-npm without the separate -bin subpackages like we have for the versioned packages?
> > I don't think the separate unversioned -bin packages make sense here, since AFAIU the goal of the unversioned metapackages is for users to always get the primary version and have that be the system default.
>
> The "and" in the last sentence was not in the original idea. I have
> always seen those two as orthogonal: You have `nodejs` installed when
> you want to "roll"/"autoinstall" the distro-recommended stream, but
> that doesn't say anything about which stream is `/usr/bin/node`. If
> you want the symlink to also follow the recommendation, you'll have
> `nodejs-bin` installed*in addition*.
>
> Granted, I don't think many people would use it this way, so I'm
> willing to not provide this option if it causes problems; but I would
> not remove it just to reduce the number of generated packages.

I think it just adds unnecessary confusion and complexity to uncouple 
these ideas. If there's no guarantee that different users installing 
`nodejs` on the same version of Fedora get the same version of nodejs as 
/usr/bin/node, then I don't think having a primary version makes much 
sense at all.
> Additionaly, there is also the matter of consistency. If we keep the
> -bin packages, the rule of thumb is simple: You swap which stream is
> `/usr/bin/node` by swapping the -bin package: `dnf swap --allowerasing
> nodejs-bin nodejs24-bin`. If we get rid of them, it will now be "You
> swap the streams by swapping the -bin packages, with the exception of
> rolling stream, when you need to switch the main one": `dnf swap
> --allowerasing nodejs nodejs24-bin`. For this reason alone, I'm still
> in favor of keeping the packages around for the rolling stream as
> well.

Can nodejs Provide nodejs-bin and nodejs-npm Provide nodejs-npm-bin so 
there's not a need for two extra metapackages but "dnf swap 
--allowerasing nodejs-bin nodejs24-bin" should still work?

All the best,
Maxwell

[Jan Stanek]

Hi again!

On Tue, Jun 23, 2026 at 10:55 PM Maxwell G  wrote:
> I think it just adds unnecessary confusion and complexity to uncouple
> these ideas. If there's no guarantee that different users installing
> `nodejs` on the same version of Fedora get the same version of nodejs as
> /usr/bin/node, then I don't think having a primary version makes much
> sense at all.

On clean system, they will – `dnf install nodejs` should pull
`nodejs-bin` and everything should work as expected, and everyone
should get the same version.
The problem might occur if you already have a non-default stream (e.g.
nodejs26 which pulled nodejs26-bin) and then try to install just
`nodejs`.
With the split approach, you'll get `nodejs` and e.g. `nodejs24`
installed, but /usr/bin/node will still point to /usr/bin/node-26.
With the merged approach, you'll get an error (conflicting packages
being installed) and will be forced to `dnf swap` into nodejs (rolling
stream).

So the question really is whether it is worth supporting the use case
where you want both of:
1. Having a control over which nodejs is your system default
(/usr/bin/node) *and*
2. Having a new "default" stream installed for you on `dnf
system-upgrade` without necessarily re-pointing /usr/bin/node to it.

I'm not convinced it is, so this is actually an argument in favor of
the merged approach.
> Can nodejs Provide nodejs-bin and nodejs-npm Provide nodejs-npm-bin so
> there's not a need for two extra metapackages but "dnf swap
> --allowerasing nodejs-bin nodejs24-bin" should still work?

I was under the impression that `dnf swap` would not work with virtual
provides, but according to the manual, it should.
It's still worth testing, but I now consider that viable.
That also mean that this decision does not have to be final, and we
can always reverse course via the right Provides/Obsoletes shuffling
without affecting user experience.

Having written this analysis, I start to think the user experience
might be better with the merged approach, even though it's paid for
with greater complexity within the spec file.
I'll think it over. If someone else has an opinion on this topic, now
is a good time to voice it – even just a +1 for one of the options
will help inform the decision. (Maxwell, I already count you as +1 for
the merged approach, of course.)

Best regards, and thanks for the responses!