On Tue, Aug 5, 2025 at 12:01 PM Stephen Gallagher <sgall...@redhat.com> wrote: > > 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 package naming guidelines discourage the suffix "-latest" because it often becomes misleading over time. https://docs.fedoraproject.org/en-US/packaging-guidelines/Naming/#multiple I think Python would be great example to follow here. There are source packages for each "major" version, and every Fedora release one of those source packages enables the main_python condition to switch the binary package names from python%{pybasever} to python3. In simplified terms of source rpm to binary rpm per release: f42: python3.12 -> python3.12 python3.13 -> python3 python3.14 -> python3.14 f43: python3.12 -> python3.12 python3.13 -> python3.13 python3.14 -> python3 This gives users the flexibility to choose newer (or older) versions, or use the default python3 that sticks to one major version for the duration of that Fedora release. It also makes it easier for packagers to introduce new upstream versions to existing Fedora releases. This setup works well, and I Fedora would be better off if we start standardizing this approach in more packages, rather than asking users to understand different patterns for each language stack and risking missed expectations. > 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. > > > 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 -- Carl George -- _______________________________________________ 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
