On Wed, Sep 7, 2022 at 1:41 PM Stephen Gallagher <sgallagh@xxxxxxxxxx> wrote: > > 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? 3a. If you want to, though I thought you decoupled npm already. I reviewed a split out npm package, so I assume we're not multiversioning npm anymore. 3b. I think by virtue of the split npm package, we are? -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ 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
