On Tue, Aug 5, 2025 at 7:11 PM Carl George <c...@redhat.com> wrote: > > 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. >
You are describing the exact approach that they are in the process of replacing. -- _______________________________________________ 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
