Re: F38 proposal: Node.js Repackaging (Self-Contained Change proposal)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




Dne 07. 09. 22 v 19:41 Stephen Gallagher napsal(a):
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.


Just FTR, in Ruby we are using `Provides: ruby(runtime_executable) = %{ruby_release}` [1] for the similar purpose. This comes from the days we had JRuby available as and alternative implementation.

BTW I don't want to derails this discussion too much, but there are also alternative JS runtimes to Node.js, maybe it would make sense to consider them.

Vít


[1] https://src.fedoraproject.org/rpms/ruby/blob/c2026da1750e6d0cc70c7370a0840628bbbfa965/f/ruby.spec#_241


  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

Attachment: OpenPGP_signature
Description: OpenPGP digital signature

_______________________________________________
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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux