On Wed, Sep 7, 2022 at 1:56 PM Neal Gompa <ngompa13@xxxxxxxxx> wrote: > > 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? I prepared a decoupled npm package but I haven't actually built it in Fedora yet, so we're not committed to it. _______________________________________________ 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
