++ to that Upon last iteration we decided that we are not going to deprecate current functionality `if fedora == 43; generate unversioned nodejs from this srpm', but rather move it to unversioned nodejs srpm: 'if fedora == 43; *pull* nodejs24 and its -bin packages'.
That, in my opinion, is a bit cleaner solution, as versioned streams could then be independent, and by default pull only core nodejs and libs, and if you need, you could pull -bin and npm-bin explicitly. Or otherwise opt in for 'dnf install nodejs' and we will pull everything for you. On Thu, Aug 7, 2025 at 11:44 AM Vít Ondruch <vondr...@redhat.com> wrote: > > Dne 05. 08. 25 v 19:01 Stephen Gallagher napsal(a): > > On Tue, Aug 5, 2025 at 11:10 AM Jan Stanek <jsta...@redhat.com> wrote: > >> On Tue, Aug 5, 2025 at 4:37 PM Stephen Gallagher <sgall...@redhat.com> > wrote: > >>> Also be aware that you'll need to figure out what to do about `npm` > >>> and other tools that are bundled with the interpreter. They might need > >>> their own subpackages. > >> Yeah, we are aware, but here it will depend on what the actual use > >> cases are/will be. > >> We'll start with providing just `nodejs` and see what breaks (in the > >> testing side-tag). > >> > >>> I'm curious why you're back-tracking here, though. I thought the > >>> entire point of the other Changes was that you did *not* want to have > >>> an opinionated `nodejs` package. The solution you're coming up with is > >>> starting to asymptotically approach the solution you are replacing. > >> Well, we are trying to do this (slightly) differently. This thread is > >> related to the metapackage proposal [1]; > >> the TLDR would be that the opinionated `nodejs` package should be > *optional* > >> – by having the nodejs and e.g. nodejs24 names provided by separate > rpms, > >> we can differentiate between "I want any nodejs, don't care about > >> major version and it can change" > >> and "I want nodejs v24.x, keep it at that release stream". > >> > >> [1]: https://fedoraproject.org/wiki/Changes/NodeJSMetapackages > >> > >> The `nodejs` name could be provided by any of the versioned streams as > >> another subpackage, > >> but given that it may very well end up being a set of packages/names, > >> having a separate spec file for that looks easier from the maintenance > >> perspective. > >> Hence why we want to resurrect the actual nodejs package. > >> > >>> I assume this is part of the solution to my question: "What happens > >>> upon upgrade between Fedora releases?" > >>> > >>> I guess `nodejs` package would carry the latest even-numbered > >>> (destined for LTS) release available at the time of Fedora release. > >>> (Given the Node.js release cycle, this doesn't line up perfectly, as > >>> even-numbered Fedora Betas are in February, where Node.js releases > >>> two-to-four weeks after our GA. So presumably we'd expect to ship v24 > >>> (released in May) as the default Node.js in F43 and F44 and then v26 > >>> in Fedora 45 and 46 (and so on). Those Node.js versions would still > >>> turn up as non-default options in one prior Fedora release. Do I have > >>> that correct? > >> The whole purpose of the `nodejs` package is to pull whichever > >> `nodejsXY` package we deem appropriate as the "default" or "any" > >> version; it will otherwise be empty. > >> For what we deem appropriate, it will probably follow what you > >> described above; but given that one of the documented non-guarantees > >> of the `nodejs` would be that the version can change even during the > >> lifetime of a single distribution release (e.g. F43), > > That would be in violation of our stable updates policy and would need > > a special FESCo exemption. It would require a compelling argument > > (like: "upstream changed its mind on how long it would be supported"). > > > >> we can be a bit more flexible with selecting the version. If you don't > >> want to be upgraded from eg. N24 to N26 during the lifetime of the > >> Fedora release, you would be encouraged to select and install a stream > >> specifically (e.g. `dnf install nodejs24`). > > That's the opposite of the users' expectation. If you want to have > > something like that, a better choice is to offer a `nodejs-latest` > > package that always tracks the newest version (which could include the > > odd-numbered Node.js releases, I'd expect). Users on that path would > > have to understand that they would regularly encounter > > backwards-incompatible changes. > > > > The default assumption has to be that the user experience doesn't > > change once the user installs something unless it is absolutely > > necessary. Node.js has compatibility breaks with every release (hence > > why the major version changes) and thus should not change during a > > single Fedora cycle. > > > I believe it is safe to say that this proposal allows flexibility. The > rest is about policies how we use the flexibility. > > I think it is fine if for specific Fedora version, the `dnf install > nodejs` pulls in always the same specific Node.js version. Where on > system upgrade to newer Fedora version, this allows the newer Node.js > version to be pulled in. > > E.g. for lets say Fedora 43, `dnf install nodejs` will always install > Node.js 24. Given the Fedora and Node.js lifecycles, that also means F44 > will keep using Node.js 24 while system upgrade to F45 will pull in > Node.js 26. > > > > Vít > > > > > >> To answer your original question here, upgrade to Fedora releases here > >> is treated as any other upgrades in this specific case – `nodejs` > >> would be potentially updated to a new version; if that version depends > >> on newer `nodejsXY`, the newer stream will be pulled as a dependency. > >> The old one might be kept and updated, or removed as no-longer-needed > >> dependency (depends on the dnf and whether it was ever marked as > >> explicitly installed). > >> > >> Hope this sheds some light on the matter. > >> Best regards! > >> -- > >> > >> Jan Stanek > >> > >> Software Engineer > >> > >> Red Hat > >> > >> IM: @jstanek > >> > >> -- > >> _______________________________________________ > >> devel mailing list -- devel@lists.fedoraproject.org > >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org > >> Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > >> List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > >> Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > -- > _______________________________________________ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue >
-- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
