On Wed, Sep 7, 2022 at 1:32 PM Neal Gompa <ngompa13@xxxxxxxxx> wrote: > > On Wed, Sep 7, 2022 at 12:45 PM Stephen Gallagher <sgallagh@xxxxxxxxxx> wrote: > > > > On Wed, Sep 7, 2022 at 9:03 AM Neal Gompa <ngompa13@xxxxxxxxx> wrote: > > > > > > On Wed, Sep 7, 2022 at 2:49 AM Vitaly Zaitsev via devel > > > <devel@xxxxxxxxxxxxxxxxxxxxxxx> 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 default > > > > > Node.js version for that release, or if the default is not installed, > > > > > > > > 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 > > `/etc/alternatives/state`. > > 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[1]. On both my Silverblue main system and Fedora IoT RPi system, /var/lib/alternatives is actually a symlink to ../../usr/lib/alternatives I think that means that the alternatives system "works" but the user cannot change it. Maybe we can ask for that to move to ../../etc/alternatives/state instead? > > It might be worth exploring for this... > > That said, I don't think alternatives makes sense for this case. > > [1]: https://copr.fedorainfracloud.org/coprs/ngompa/alts/build/4815991/ Moving this conversation from nodejs@xxxxxxxx.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@xxxxxxxxxx> wrote: > > And 3 more for "stick with whatever ships with the version of node they're using" > > On Wed, Sep 7, 2022 at 11:18 AM Michael Dawson <midawson@xxxxxxxxxx> 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@xxxxxxxxx> wrote: >>> >>> On Wed, Sep 7, 2022 at 9:47 AM Michael Dawson <midawson@xxxxxxxxxx> 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 Node.js/JavaScript chat room to see what other people think. >>> > >>> >>> 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 alternatives system. 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 npm package? b. Do we allow users to mix-and-match the npm default independently to Node.js? _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
