The current implementation of alternative nodejs versions in a single Fedora (say 38), is this: * the main version (v18 in F38) ships /usr/bin/node * alternative versions ship only /usr/bin/node-XX
Node modules packaged as RPM (e.g. nodejs-nodemon) then often include this hard dependency: Requires: /usr/bin/node
Suppose I want to install only the alternative (non-default) version of node and install a module nodejs-nodemon (that can run fine with any nodejs version). I cannot do this at this point, because the nodejs-nodemon pulls in the default node as a dependency.
New proposal: use a concept that has proofed to work for ruby for longer time (except it's used for alternative implementations, rather than alternative versions, but the logic is similar) -- rubypick package ships /usr/bin/ruby that is actually a simple shell script. This script executes a particular binary of ruby based on a reasonable defaults, explicit parameters of environment variables.
How it would work for node: The default nodejs version would ship a new sub-package called "nodepick", which would only ship a couple of shell scripts: /usr/bin/node, /usr/bin/npm, etc.. All nodejs versions (including the default one) would only ship versioned binaries /usr/bin/node-XX. The shell scripts would execute a particular versioned binary based on some reasonable logic (environment variables, default, available version)...
From the RPM metadata perspective: There would need to be some soft dependency from nodepick -> node-XX, with priority for the default version (dnf honours priority by Suggests I think), and a hard dependency of each of the nodejs-XX -> nodepick.
Thoughts?
Honza
CCing Michael from the node.js upstream to share his opinion on this idea as well.
Honza
On Tue, Jul 11, 2023 at 5:17 PM Honza Horak hhorak@redhat.com wrote:
The current implementation of alternative nodejs versions in a single Fedora (say 38), is this:
- the main version (v18 in F38) ships /usr/bin/node
- alternative versions ship only /usr/bin/node-XX
Node modules packaged as RPM (e.g. nodejs-nodemon) then often include this hard dependency: Requires: /usr/bin/node
Suppose I want to install only the alternative (non-default) version of node and install a module nodejs-nodemon (that can run fine with any nodejs version). I cannot do this at this point, because the nodejs-nodemon pulls in the default node as a dependency.
New proposal: use a concept that has proofed to work for ruby for longer time (except it's used for alternative implementations, rather than alternative versions, but the logic is similar) -- rubypick package ships /usr/bin/ruby that is actually a simple shell script. This script executes a particular binary of ruby based on a reasonable defaults, explicit parameters of environment variables.
How it would work for node: The default nodejs version would ship a new sub-package called "nodepick", which would only ship a couple of shell scripts: /usr/bin/node, /usr/bin/npm, etc.. All nodejs versions (including the default one) would only ship versioned binaries /usr/bin/node-XX. The shell scripts would execute a particular versioned binary based on some reasonable logic (environment variables, default, available version)...
From the RPM metadata perspective: There would need to be some soft dependency from nodepick -> node-XX, with priority for the default version (dnf honours priority by Suggests I think), and a hard dependency of each of the nodejs-XX -> nodepick.
Thoughts?
Honza
On Tue, Jul 11, 2023 at 11:19 AM Honza Horak hhorak@redhat.com wrote:
The current implementation of alternative nodejs versions in a single Fedora (say 38), is this:
- the main version (v18 in F38) ships /usr/bin/node
- alternative versions ship only /usr/bin/node-XX
Node modules packaged as RPM (e.g. nodejs-nodemon) then often include this hard dependency: Requires: /usr/bin/node
Suppose I want to install only the alternative (non-default) version of node and install a module nodejs-nodemon (that can run fine with any nodejs version). I cannot do this at this point, because the nodejs-nodemon pulls in the default node as a dependency.
I think you need to be more explicit about why you want to only install a non-default version AND run this tool. This is very much part of the design: applications packaged in Fedora RPMs are not expected to be runnable against an arbitrary Node binary. They specify the one they are known to work with explicitly through package dependencies.
What is the use-case you're actually trying to solve?
Sure. My current use case is preparing a nodejs v20 container image similar to previous versions at [1]. I want to use the latest stable fedora and explicitly want only nodejs v20 in the container (which is not the default one in F38).
I also want to install nodejs-nodemon into the container to make the feature set to be on pair with previous versions, but that ends up with pulling nodejs 18 (the default) as well, because of the dependency on /usr/bin/node.
Having different versions of packages like nodejs-nodemon in Fedora repos does not seem to be technically needed, one RPM build seems to be fine for more nodejs versions. I believe we did it the same in previous design with modules -- we only installed nodejs and npm from the module, but had nodejs-nodemon available in the repos in a single instance and it worked fine with all nodejs versions.
Does that make more sense now? Maybe I'm trying to solve it too complicated, feel free to suggest any other solution.
[1] https://github.com/sclorg/s2i-nodejs-container/
Honza
On Tue, Jul 11, 2023 at 7:27 PM Stephen Gallagher sgallagh@redhat.com wrote:
On Tue, Jul 11, 2023 at 11:19 AM Honza Horak hhorak@redhat.com wrote:
The current implementation of alternative nodejs versions in a single
Fedora (say 38), is this:
- the main version (v18 in F38) ships /usr/bin/node
- alternative versions ship only /usr/bin/node-XX
Node modules packaged as RPM (e.g. nodejs-nodemon) then often include
this hard dependency: Requires: /usr/bin/node
Suppose I want to install only the alternative (non-default) version of
node and install a module nodejs-nodemon (that can run fine with any nodejs version). I cannot do this at this point, because the nodejs-nodemon pulls in the default node as a dependency.
I think you need to be more explicit about why you want to only install a non-default version AND run this tool. This is very much part of the design: applications packaged in Fedora RPMs are not expected to be runnable against an arbitrary Node binary. They specify the one they are known to work with explicitly through package dependencies.
What is the use-case you're actually trying to solve? _______________________________________________ nodejs mailing list -- nodejs@lists.fedoraproject.org To unsubscribe send an email to nodejs-leave@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/nodejs@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
My concern is the customer use case. They have installed a third party application which will be expecting to use the name "node" versus one that is tied to the version. We want them to be able to easily use versions which are not the default because the default Node.js for a RHEL release will be EOL long before the version of RHEL is.
On Wed, Jul 12, 2023 at 3:42 AM Honza Horak hhorak@redhat.com wrote:
Sure. My current use case is preparing a nodejs v20 container image similar to previous versions at [1]. I want to use the latest stable fedora and explicitly want only nodejs v20 in the container (which is not the default one in F38).
I also want to install nodejs-nodemon into the container to make the feature set to be on pair with previous versions, but that ends up with pulling nodejs 18 (the default) as well, because of the dependency on /usr/bin/node.
Having different versions of packages like nodejs-nodemon in Fedora repos does not seem to be technically needed, one RPM build seems to be fine for more nodejs versions. I believe we did it the same in previous design with modules -- we only installed nodejs and npm from the module, but had nodejs-nodemon available in the repos in a single instance and it worked fine with all nodejs versions.
Does that make more sense now? Maybe I'm trying to solve it too complicated, feel free to suggest any other solution.
[1] https://github.com/sclorg/s2i-nodejs-container/
Honza
On Tue, Jul 11, 2023 at 7:27 PM Stephen Gallagher sgallagh@redhat.com wrote:
On Tue, Jul 11, 2023 at 11:19 AM Honza Horak hhorak@redhat.com wrote:
The current implementation of alternative nodejs versions in a single
Fedora (say 38), is this:
- the main version (v18 in F38) ships /usr/bin/node
- alternative versions ship only /usr/bin/node-XX
Node modules packaged as RPM (e.g. nodejs-nodemon) then often include
this hard dependency: Requires: /usr/bin/node
Suppose I want to install only the alternative (non-default) version of
node and install a module nodejs-nodemon (that can run fine with any nodejs version). I cannot do this at this point, because the nodejs-nodemon pulls in the default node as a dependency.
I think you need to be more explicit about why you want to only install a non-default version AND run this tool. This is very much part of the design: applications packaged in Fedora RPMs are not expected to be runnable against an arbitrary Node binary. They specify the one they are known to work with explicitly through package dependencies.
What is the use-case you're actually trying to solve? _______________________________________________ nodejs mailing list -- nodejs@lists.fedoraproject.org To unsubscribe send an email to nodejs-leave@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/nodejs@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
nodejs mailing list -- nodejs@lists.fedoraproject.org To unsubscribe send an email to nodejs-leave@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/nodejs@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Unless I interpret it wrong, you're saying that we actually need some flexibility in what /usr/bin/node means, which is the same thing I'm saying. Of course, the implementation of how to achieve this might change.
Honza
On Wed, Jul 12, 2023 at 4:34 PM Michael Dawson midawson@redhat.com wrote:
My concern is the customer use case. They have installed a third party application which will be expecting to use the name "node" versus one that is tied to the version. We want them to be able to easily use versions which are not the default because the default Node.js for a RHEL release will be EOL long before the version of RHEL is.
On Wed, Jul 12, 2023 at 3:42 AM Honza Horak hhorak@redhat.com wrote:
Sure. My current use case is preparing a nodejs v20 container image similar to previous versions at [1]. I want to use the latest stable fedora and explicitly want only nodejs v20 in the container (which is not the default one in F38).
I also want to install nodejs-nodemon into the container to make the feature set to be on pair with previous versions, but that ends up with pulling nodejs 18 (the default) as well, because of the dependency on /usr/bin/node.
Having different versions of packages like nodejs-nodemon in Fedora repos does not seem to be technically needed, one RPM build seems to be fine for more nodejs versions. I believe we did it the same in previous design with modules -- we only installed nodejs and npm from the module, but had nodejs-nodemon available in the repos in a single instance and it worked fine with all nodejs versions.
Does that make more sense now? Maybe I'm trying to solve it too complicated, feel free to suggest any other solution.
[1] https://github.com/sclorg/s2i-nodejs-container/
Honza
On Tue, Jul 11, 2023 at 7:27 PM Stephen Gallagher sgallagh@redhat.com wrote:
On Tue, Jul 11, 2023 at 11:19 AM Honza Horak hhorak@redhat.com wrote:
The current implementation of alternative nodejs versions in a single
Fedora (say 38), is this:
- the main version (v18 in F38) ships /usr/bin/node
- alternative versions ship only /usr/bin/node-XX
Node modules packaged as RPM (e.g. nodejs-nodemon) then often include
this hard dependency: Requires: /usr/bin/node
Suppose I want to install only the alternative (non-default) version
of node and install a module nodejs-nodemon (that can run fine with any nodejs version). I cannot do this at this point, because the nodejs-nodemon pulls in the default node as a dependency.
I think you need to be more explicit about why you want to only install a non-default version AND run this tool. This is very much part of the design: applications packaged in Fedora RPMs are not expected to be runnable against an arbitrary Node binary. They specify the one they are known to work with explicitly through package dependencies.
What is the use-case you're actually trying to solve? _______________________________________________ nodejs mailing list -- nodejs@lists.fedoraproject.org To unsubscribe send an email to nodejs-leave@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/nodejs@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
nodejs mailing list -- nodejs@lists.fedoraproject.org To unsubscribe send an email to nodejs-leave@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/nodejs@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
nodejs mailing list -- nodejs@lists.fedoraproject.org To unsubscribe send an email to nodejs-leave@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/nodejs@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Honza, correct.
I was just trying to add that it's not just about consumption in RHEL packages that use Node.js, but also customer applications and third party applications that they might be running.
On Thu, Jul 13, 2023 at 6:35 AM Honza Horak hhorak@redhat.com wrote:
Unless I interpret it wrong, you're saying that we actually need some flexibility in what /usr/bin/node means, which is the same thing I'm saying. Of course, the implementation of how to achieve this might change.
Honza
On Wed, Jul 12, 2023 at 4:34 PM Michael Dawson midawson@redhat.com wrote:
My concern is the customer use case. They have installed a third party application which will be expecting to use the name "node" versus one that is tied to the version. We want them to be able to easily use versions which are not the default because the default Node.js for a RHEL release will be EOL long before the version of RHEL is.
On Wed, Jul 12, 2023 at 3:42 AM Honza Horak hhorak@redhat.com wrote:
Sure. My current use case is preparing a nodejs v20 container image similar to previous versions at [1]. I want to use the latest stable fedora and explicitly want only nodejs v20 in the container (which is not the default one in F38).
I also want to install nodejs-nodemon into the container to make the feature set to be on pair with previous versions, but that ends up with pulling nodejs 18 (the default) as well, because of the dependency on /usr/bin/node.
Having different versions of packages like nodejs-nodemon in Fedora repos does not seem to be technically needed, one RPM build seems to be fine for more nodejs versions. I believe we did it the same in previous design with modules -- we only installed nodejs and npm from the module, but had nodejs-nodemon available in the repos in a single instance and it worked fine with all nodejs versions.
Does that make more sense now? Maybe I'm trying to solve it too complicated, feel free to suggest any other solution.
[1] https://github.com/sclorg/s2i-nodejs-container/
Honza
On Tue, Jul 11, 2023 at 7:27 PM Stephen Gallagher sgallagh@redhat.com wrote:
On Tue, Jul 11, 2023 at 11:19 AM Honza Horak hhorak@redhat.com wrote:
The current implementation of alternative nodejs versions in a single
Fedora (say 38), is this:
- the main version (v18 in F38) ships /usr/bin/node
- alternative versions ship only /usr/bin/node-XX
Node modules packaged as RPM (e.g. nodejs-nodemon) then often include
this hard dependency: Requires: /usr/bin/node
Suppose I want to install only the alternative (non-default) version
of node and install a module nodejs-nodemon (that can run fine with any nodejs version). I cannot do this at this point, because the nodejs-nodemon pulls in the default node as a dependency.
I think you need to be more explicit about why you want to only install a non-default version AND run this tool. This is very much part of the design: applications packaged in Fedora RPMs are not expected to be runnable against an arbitrary Node binary. They specify the one they are known to work with explicitly through package dependencies.
What is the use-case you're actually trying to solve? _______________________________________________ nodejs mailing list -- nodejs@lists.fedoraproject.org To unsubscribe send an email to nodejs-leave@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/nodejs@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
nodejs mailing list -- nodejs@lists.fedoraproject.org To unsubscribe send an email to nodejs-leave@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/nodejs@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
nodejs mailing list -- nodejs@lists.fedoraproject.org To unsubscribe send an email to nodejs-leave@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/nodejs@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On Thu, Jul 13, 2023 at 10:36 AM Michael Dawson midawson@redhat.com wrote:
Honza, correct.
I was just trying to add that it's not just about consumption in RHEL packages that use Node.js, but also customer applications and third party applications that they might be running.
On Thu, Jul 13, 2023 at 6:35 AM Honza Horak hhorak@redhat.com wrote:
Unless I interpret it wrong, you're saying that we actually need some flexibility in what /usr/bin/node means, which is the same thing I'm saying. Of course, the implementation of how to achieve this might change.
Honza
On Wed, Jul 12, 2023 at 4:34 PM Michael Dawson midawson@redhat.com wrote:
My concern is the customer use case. They have installed a third party application which will be expecting to use the name "node" versus one that is tied to the version. We want them to be able to easily use versions which are not the default because the default Node.js for a RHEL release will be EOL long before the version of RHEL is.
On Wed, Jul 12, 2023 at 3:42 AM Honza Horak hhorak@redhat.com wrote:
Sure. My current use case is preparing a nodejs v20 container image similar to previous versions at [1]. I want to use the latest stable fedora and explicitly want only nodejs v20 in the container (which is not the default one in F38).
I also want to install nodejs-nodemon into the container to make the feature set to be on pair with previous versions, but that ends up with pulling nodejs 18 (the default) as well, because of the dependency on /usr/bin/node.
Having different versions of packages like nodejs-nodemon in Fedora repos does not seem to be technically needed, one RPM build seems to be fine for more nodejs versions. I believe we did it the same in previous design with modules -- we only installed nodejs and npm from the module, but had nodejs-nodemon available in the repos in a single instance and it worked fine with all nodejs versions.
Does that make more sense now? Maybe I'm trying to solve it too complicated, feel free to suggest any other solution.
[1] https://github.com/sclorg/s2i-nodejs-container/
Honza
Sorry for the long silence on this; I've been swamped (and had PTO).
So, we have a number of competing requirements here:
1) Each Fedora release must have a default version of Node.js that is pulled in when "nodejs" or "/usr/bin/node" is requested. 2) Fedora needs to be able to upgrade to a new release, possibly also upgrading the default version of Node.js in the process. 3) Each Fedora release *may* have additional non-default Node.js versions available in the repository. 4) Per packaging rules in Fedora, additional software that depends on Node.js must either support the default version (using /usr/bin/node) or it must modify its packaging to use a non-default path (/usr/bin/nodejsNN). This is so that installing any particular package (even if it requires a non-default Node version) does not preclude installing the default version.
And now, from you: 5) It must be possible to reassign the symlink "/usr/bin/node" to a non-default version (e.g. /usr/bin/node-18)
I explored this option 5) when I originally demodularized Node.js, but it's *extremely* complicated. Not least because we have multiple applications that are codependent, such as NPM. If we change /usr/bin/node, we also need to change /usr/bin/npm (and npx, and...) to match. Initially, I used the "alternatives" subsystem to accomplish this, but it ran into quite a few unexpected issues. (The complete discussion is elsewhere on the fedora-devel and nodejs lists. Look for "Node.js repackaging" threads)
I'm not ruling out the possibility of a solution, but at least one of the above constraints would have to go away. My recommendation is that we document instead that the recommendation for creating a non-default Node container is to manually add the desired symlinks. Maybe we (Fedora) could just ship a container base image that does this for the user?
On Tue, Aug 8, 2023 at 3:18 PM Stephen Gallagher sgallagh@redhat.com wrote:
On Thu, Jul 13, 2023 at 10:36 AM Michael Dawson midawson@redhat.com wrote:
Honza, correct.
I was just trying to add that it's not just about consumption in RHEL
packages that use Node.js, but also customer applications and third party applications that they might be running.
On Thu, Jul 13, 2023 at 6:35 AM Honza Horak hhorak@redhat.com wrote:
Unless I interpret it wrong, you're saying that we actually need some
flexibility in what /usr/bin/node means, which is the same thing I'm saying. Of course, the implementation of how to achieve this might change.
Honza
On Wed, Jul 12, 2023 at 4:34 PM Michael Dawson midawson@redhat.com
wrote:
My concern is the customer use case. They have installed a third party
application which will be expecting to use the name "node" versus one that is tied to the version. We want them to be able to easily use versions which are not the default because the default Node.js for a RHEL release will be EOL long before the version of RHEL is.
On Wed, Jul 12, 2023 at 3:42 AM Honza Horak hhorak@redhat.com wrote:
Sure. My current use case is preparing a nodejs v20 container image
similar to previous versions at [1]. I want to use the latest stable fedora and explicitly want only nodejs v20 in the container (which is not the default one in F38).
I also want to install nodejs-nodemon into the container to make the
feature set to be on pair with previous versions, but that ends up with pulling nodejs 18 (the default) as well, because of the dependency on /usr/bin/node.
Having different versions of packages like nodejs-nodemon in Fedora
repos does not seem to be technically needed, one RPM build seems to be fine for more nodejs versions. I believe we did it the same in previous design with modules -- we only installed nodejs and npm from the module, but had nodejs-nodemon available in the repos in a single instance and it worked fine with all nodejs versions.
Does that make more sense now? Maybe I'm trying to solve it too
complicated, feel free to suggest any other solution.
[1] https://github.com/sclorg/s2i-nodejs-container/
Honza
Sorry for the long silence on this; I've been swamped (and had PTO).
So, we have a number of competing requirements here:
- Each Fedora release must have a default version of Node.js that is
pulled in when "nodejs" or "/usr/bin/node" is requested. 2) Fedora needs to be able to upgrade to a new release, possibly also upgrading the default version of Node.js in the process. 3) Each Fedora release *may* have additional non-default Node.js versions available in the repository. 4) Per packaging rules in Fedora, additional software that depends on Node.js must either support the default version (using /usr/bin/node) or it must modify its packaging to use a non-default path (/usr/bin/nodejsNN). This is so that installing any particular package (even if it requires a non-default Node version) does not preclude installing the default version.
And now, from you: 5) It must be possible to reassign the symlink "/usr/bin/node" to a non-default version (e.g. /usr/bin/node-18)
I explored this option 5) when I originally demodularized Node.js, but it's *extremely* complicated. Not least because we have multiple applications that are codependent, such as NPM. If we change /usr/bin/node, we also need to change /usr/bin/npm (and npx, and...) to match. Initially, I used the "alternatives" subsystem to accomplish this, but it ran into quite a few unexpected issues. (The complete discussion is elsewhere on the fedora-devel and nodejs lists. Look for "Node.js repackaging" threads)
Yes, "alternatives" are tricky, we learned it the hard way when introduced python into RHEL-8 as well.
I'm not ruling out the possibility of a solution, but at least one of the above constraints would have to go away. My recommendation is that we document instead that the recommendation for creating a non-default Node container is to manually add the desired symlinks. Maybe we (Fedora) could just ship a container base image that does this for the user?
We already ship container images, e.g.: https://quay.io/repository/fedora/nodejs-18?tab=tags&tag=latest This thread was motivated by not being able to do the same for nodejs-20 when using F38 as a base.
The problem is that creating a symlink does not help us to install nodejs-nodemon package. We can make it work by changing the requirements of nodejs-nodemon so it is ok with any nodejs version, to "Requires: nodejs(engine)". This, in compbination with creating symlinks /usr/bin/{node,npm,npx} in the container might fix my issue.
Honza
On Tue, Aug 8, 2023 at 10:09 AM Honza Horak hhorak@redhat.com wrote:
On Tue, Aug 8, 2023 at 3:18 PM Stephen Gallagher sgallagh@redhat.com wrote:
On Thu, Jul 13, 2023 at 10:36 AM Michael Dawson midawson@redhat.com wrote:
Honza, correct.
I was just trying to add that it's not just about consumption in RHEL packages that use Node.js, but also customer applications and third party applications that they might be running.
On Thu, Jul 13, 2023 at 6:35 AM Honza Horak hhorak@redhat.com wrote:
Unless I interpret it wrong, you're saying that we actually need some flexibility in what /usr/bin/node means, which is the same thing I'm saying. Of course, the implementation of how to achieve this might change.
Honza
On Wed, Jul 12, 2023 at 4:34 PM Michael Dawson midawson@redhat.com wrote:
My concern is the customer use case. They have installed a third party application which will be expecting to use the name "node" versus one that is tied to the version. We want them to be able to easily use versions which are not the default because the default Node.js for a RHEL release will be EOL long before the version of RHEL is.
On Wed, Jul 12, 2023 at 3:42 AM Honza Horak hhorak@redhat.com wrote:
Sure. My current use case is preparing a nodejs v20 container image similar to previous versions at [1]. I want to use the latest stable fedora and explicitly want only nodejs v20 in the container (which is not the default one in F38).
I also want to install nodejs-nodemon into the container to make the feature set to be on pair with previous versions, but that ends up with pulling nodejs 18 (the default) as well, because of the dependency on /usr/bin/node.
Having different versions of packages like nodejs-nodemon in Fedora repos does not seem to be technically needed, one RPM build seems to be fine for more nodejs versions. I believe we did it the same in previous design with modules -- we only installed nodejs and npm from the module, but had nodejs-nodemon available in the repos in a single instance and it worked fine with all nodejs versions.
Does that make more sense now? Maybe I'm trying to solve it too complicated, feel free to suggest any other solution.
[1] https://github.com/sclorg/s2i-nodejs-container/
Honza
Sorry for the long silence on this; I've been swamped (and had PTO).
So, we have a number of competing requirements here:
- Each Fedora release must have a default version of Node.js that is
pulled in when "nodejs" or "/usr/bin/node" is requested. 2) Fedora needs to be able to upgrade to a new release, possibly also upgrading the default version of Node.js in the process. 3) Each Fedora release *may* have additional non-default Node.js versions available in the repository. 4) Per packaging rules in Fedora, additional software that depends on Node.js must either support the default version (using /usr/bin/node) or it must modify its packaging to use a non-default path (/usr/bin/nodejsNN). This is so that installing any particular package (even if it requires a non-default Node version) does not preclude installing the default version.
And now, from you: 5) It must be possible to reassign the symlink "/usr/bin/node" to a non-default version (e.g. /usr/bin/node-18)
I explored this option 5) when I originally demodularized Node.js, but it's *extremely* complicated. Not least because we have multiple applications that are codependent, such as NPM. If we change /usr/bin/node, we also need to change /usr/bin/npm (and npx, and...) to match. Initially, I used the "alternatives" subsystem to accomplish this, but it ran into quite a few unexpected issues. (The complete discussion is elsewhere on the fedora-devel and nodejs lists. Look for "Node.js repackaging" threads)
Yes, "alternatives" are tricky, we learned it the hard way when introduced python into RHEL-8 as well.
I'm not ruling out the possibility of a solution, but at least one of the above constraints would have to go away. My recommendation is that we document instead that the recommendation for creating a non-default Node container is to manually add the desired symlinks. Maybe we (Fedora) could just ship a container base image that does this for the user?
We already ship container images, e.g.: https://quay.io/repository/fedora/nodejs-18?tab=tags&tag=latest This thread was motivated by not being able to do the same for nodejs-20 when using F38 as a base.
The problem is that creating a symlink does not help us to install nodejs-nodemon package. We can make it work by changing the requirements of nodejs-nodemon so it is ok with any nodejs version, to "Requires: nodejs(engine)". This, in compbination with creating symlinks /usr/bin/{node,npm,npx} in the container might fix my issue.
I think nodejs-nodemon might be a rare special case. Given its purpose as basically a monitor for the Node.js daemon, it might be worthwhile to actually package multiple subpackages of it, one associated with each Node.js release supported in a Fedora/RHEL release (so, /usr/bin/nodemon-18). Then in containers you could also create symlinks for nodemon in addition to /usr/bin/node and friends)
There's also a fair argument to be made for bundling nodemon into the nodejs package itself; it could be a useful differentiator for Fedora/RHEL's packaging vs. upstream/nodesource. Node.js already ships with a few bundled packages (punycode, npm, etc.). The only issue would be the release schedule; we'd need to decide when a nodemon update/CVE would justify a Node.js package update.
On Tue, Aug 8, 2023 at 4:20 PM Stephen Gallagher sgallagh@redhat.com wrote:
On Tue, Aug 8, 2023 at 10:09 AM Honza Horak hhorak@redhat.com wrote:
On Tue, Aug 8, 2023 at 3:18 PM Stephen Gallagher sgallagh@redhat.com
wrote:
On Thu, Jul 13, 2023 at 10:36 AM Michael Dawson midawson@redhat.com
wrote:
Honza, correct.
I was just trying to add that it's not just about consumption in RHEL
packages that use Node.js, but also customer applications and third party applications that they might be running.
On Thu, Jul 13, 2023 at 6:35 AM Honza Horak hhorak@redhat.com
wrote:
Unless I interpret it wrong, you're saying that we actually need
some flexibility in what /usr/bin/node means, which is the same thing I'm saying. Of course, the implementation of how to achieve this might change.
Honza
On Wed, Jul 12, 2023 at 4:34 PM Michael Dawson midawson@redhat.com
wrote:
My concern is the customer use case. They have installed a third
party application which will be expecting to use the name "node" versus one that is tied to the version. We want them to be able to easily use versions which are not the default because the default Node.js for a RHEL release will be EOL long before the version of RHEL is.
On Wed, Jul 12, 2023 at 3:42 AM Honza Horak hhorak@redhat.com
wrote:
> > Sure. My current use case is preparing a nodejs v20 container
image similar to previous versions at [1]. I want to use the latest stable fedora and explicitly want only nodejs v20 in the container (which is not the default one in F38).
> > I also want to install nodejs-nodemon into the container to make
the feature set to be on pair with previous versions, but that ends up with pulling nodejs 18 (the default) as well, because of the dependency on /usr/bin/node.
> > Having different versions of packages like nodejs-nodemon in
Fedora repos does not seem to be technically needed, one RPM build seems to be fine for more nodejs versions. I believe we did it the same in previous design with modules -- we only installed nodejs and npm from the module, but had nodejs-nodemon available in the repos in a single instance and it worked fine with all nodejs versions.
> > Does that make more sense now? Maybe I'm trying to solve it too
complicated, feel free to suggest any other solution.
> > [1] https://github.com/sclorg/s2i-nodejs-container/ > > Honza >
Sorry for the long silence on this; I've been swamped (and had PTO).
So, we have a number of competing requirements here:
- Each Fedora release must have a default version of Node.js that is
pulled in when "nodejs" or "/usr/bin/node" is requested. 2) Fedora needs to be able to upgrade to a new release, possibly also upgrading the default version of Node.js in the process. 3) Each Fedora release *may* have additional non-default Node.js versions available in the repository. 4) Per packaging rules in Fedora, additional software that depends on Node.js must either support the default version (using /usr/bin/node) or it must modify its packaging to use a non-default path (/usr/bin/nodejsNN). This is so that installing any particular package (even if it requires a non-default Node version) does not preclude installing the default version.
And now, from you: 5) It must be possible to reassign the symlink "/usr/bin/node" to a non-default version (e.g. /usr/bin/node-18)
I explored this option 5) when I originally demodularized Node.js, but it's *extremely* complicated. Not least because we have multiple applications that are codependent, such as NPM. If we change /usr/bin/node, we also need to change /usr/bin/npm (and npx, and...) to match. Initially, I used the "alternatives" subsystem to accomplish this, but it ran into quite a few unexpected issues. (The complete discussion is elsewhere on the fedora-devel and nodejs lists. Look for "Node.js repackaging" threads)
Yes, "alternatives" are tricky, we learned it the hard way when
introduced python into RHEL-8 as well.
I'm not ruling out the possibility of a solution, but at least one of the above constraints would have to go away. My recommendation is that we document instead that the recommendation for creating a non-default Node container is to manually add the desired symlinks. Maybe we (Fedora) could just ship a container base image that does this for the user?
We already ship container images, e.g.:
https://quay.io/repository/fedora/nodejs-18?tab=tags&tag=latest
This thread was motivated by not being able to do the same for nodejs-20
when using F38 as a base.
The problem is that creating a symlink does not help us to install
nodejs-nodemon package. We can make it work by changing the requirements of nodejs-nodemon so it is ok with any nodejs version, to "Requires: nodejs(engine)". This, in compbination with creating symlinks /usr/bin/{node,npm,npx} in the container might fix my issue.
I think nodejs-nodemon might be a rare special case. Given its purpose as basically a monitor for the Node.js daemon, it might be worthwhile to actually package multiple subpackages of it, one associated with each Node.js release supported in a Fedora/RHEL release (so, /usr/bin/nodemon-18). Then in containers you could also create symlinks for nodemon in addition to /usr/bin/node and friends)
I wouldn't be against having more builds of nodemon if there was a need to have different outputs. But now, if we are ok with a single nodemon version for all nodejs streams, it's nonsense to build the same SRPM several times, especially if the binary RPMs (in this case JS code) is exactly the same. That would be wasted time.
There's also a fair argument to be made for bundling nodemon into the nodejs package itself; it could be a useful differentiator for Fedora/RHEL's packaging vs. upstream/nodesource. Node.js already ships with a few bundled packages (punycode, npm, etc.). The only issue would be the release schedule; we'd need to decide when a nodemon update/CVE would justify a Node.js package update.
Interesting idea. I can see here that the time needed multiple times for updating the version of nodemon separately for each stream (can be scripted) would be compensated by avoiding the build of nodemon separately. On the other hand, this would go against the default Fedora policy to not bundle and do it only when necessary -- this case does not seem to be necessary.
Honza
On Wed, Aug 9, 2023 at 10:07 AM Honza Horak hhorak@redhat.com wrote:
On Tue, Aug 8, 2023 at 4:20 PM Stephen Gallagher sgallagh@redhat.com wrote:
On Tue, Aug 8, 2023 at 10:09 AM Honza Horak hhorak@redhat.com wrote:
On Tue, Aug 8, 2023 at 3:18 PM Stephen Gallagher sgallagh@redhat.com
wrote:
On Thu, Jul 13, 2023 at 10:36 AM Michael Dawson midawson@redhat.com
wrote:
Honza, correct.
I was just trying to add that it's not just about consumption in
RHEL packages that use Node.js, but also customer applications and third party applications that they might be running.
On Thu, Jul 13, 2023 at 6:35 AM Honza Horak hhorak@redhat.com
wrote:
Unless I interpret it wrong, you're saying that we actually need
some flexibility in what /usr/bin/node means, which is the same thing I'm saying. Of course, the implementation of how to achieve this might change.
Honza
On Wed, Jul 12, 2023 at 4:34 PM Michael Dawson midawson@redhat.com
wrote:
> > My concern is the customer use case. They have installed a third
party application which will be expecting to use the name "node" versus one that is tied to the version. We want them to be able to easily use versions which are not the default because the default Node.js for a RHEL release will be EOL long before the version of RHEL is.
> > On Wed, Jul 12, 2023 at 3:42 AM Honza Horak hhorak@redhat.com
wrote:
>> >> Sure. My current use case is preparing a nodejs v20 container
image similar to previous versions at [1]. I want to use the latest stable fedora and explicitly want only nodejs v20 in the container (which is not the default one in F38).
>> >> I also want to install nodejs-nodemon into the container to make
the feature set to be on pair with previous versions, but that ends up with pulling nodejs 18 (the default) as well, because of the dependency on /usr/bin/node.
>> >> Having different versions of packages like nodejs-nodemon in
Fedora repos does not seem to be technically needed, one RPM build seems to be fine for more nodejs versions. I believe we did it the same in previous design with modules -- we only installed nodejs and npm from the module, but had nodejs-nodemon available in the repos in a single instance and it worked fine with all nodejs versions.
>> >> Does that make more sense now? Maybe I'm trying to solve it too
complicated, feel free to suggest any other solution.
>> >> [1] https://github.com/sclorg/s2i-nodejs-container/ >> >> Honza >>
Sorry for the long silence on this; I've been swamped (and had PTO).
So, we have a number of competing requirements here:
- Each Fedora release must have a default version of Node.js that is
pulled in when "nodejs" or "/usr/bin/node" is requested. 2) Fedora needs to be able to upgrade to a new release, possibly also upgrading the default version of Node.js in the process. 3) Each Fedora release *may* have additional non-default Node.js versions available in the repository. 4) Per packaging rules in Fedora, additional software that depends on Node.js must either support the default version (using /usr/bin/node) or it must modify its packaging to use a non-default path (/usr/bin/nodejsNN). This is so that installing any particular package (even if it requires a non-default Node version) does not preclude installing the default version.
And now, from you: 5) It must be possible to reassign the symlink "/usr/bin/node" to a non-default version (e.g. /usr/bin/node-18)
I explored this option 5) when I originally demodularized Node.js, but it's *extremely* complicated. Not least because we have multiple applications that are codependent, such as NPM. If we change /usr/bin/node, we also need to change /usr/bin/npm (and npx, and...) to match. Initially, I used the "alternatives" subsystem to accomplish this, but it ran into quite a few unexpected issues. (The complete discussion is elsewhere on the fedora-devel and nodejs lists. Look for "Node.js repackaging" threads)
Yes, "alternatives" are tricky, we learned it the hard way when
introduced python into RHEL-8 as well.
I'm not ruling out the possibility of a solution, but at least one of the above constraints would have to go away. My recommendation is that we document instead that the recommendation for creating a non-default Node container is to manually add the desired symlinks. Maybe we (Fedora) could just ship a container base image that does this for the user?
We already ship container images, e.g.:
https://quay.io/repository/fedora/nodejs-18?tab=tags&tag=latest
This thread was motivated by not being able to do the same for
nodejs-20 when using F38 as a base.
The problem is that creating a symlink does not help us to install
nodejs-nodemon package. We can make it work by changing the requirements of nodejs-nodemon so it is ok with any nodejs version, to "Requires: nodejs(engine)". This, in compbination with creating symlinks /usr/bin/{node,npm,npx} in the container might fix my issue.
I think nodejs-nodemon might be a rare special case. Given its purpose as basically a monitor for the Node.js daemon, it might be worthwhile to actually package multiple subpackages of it, one associated with each Node.js release supported in a Fedora/RHEL release (so, /usr/bin/nodemon-18). Then in containers you could also create symlinks for nodemon in addition to /usr/bin/node and friends)
I wouldn't be against having more builds of nodemon if there was a need to have different outputs. But now, if we are ok with a single nodemon version for all nodejs streams, it's nonsense to build the same SRPM several times, especially if the binary RPMs (in this case JS code) is exactly the same. That would be wasted time.
I've now realized that the paths are different, i.e. nodemon installs files into /usr/lib/node_modules_18/nodemon/.
Surprisingly, running nodemon still works even when I only install nodejs 20 into a container, likely because the /usr/bin/nodemon is a symlink to /usr/lib/node_modules_18/nodemon/bin/nodemon.js and then all the files uses relative paths. I guess this starts to fail if one would like to use nodemon library from a different context. For that case, I'd add one more symlink /usr/lib/node_modules_20/nodemon -> /usr/lib/node_modules_18/nodemon. With that, nodemon library would work even when called from a different path (not tested).
Anyway, this is a BZ tracking my issue with nodemon and some patch proposal how to address it: https://bugzilla.redhat.com/show_bug.cgi?id=2230317
Honza
There's also a fair argument to be made for bundling nodemon into the nodejs package itself; it could be a useful differentiator for Fedora/RHEL's packaging vs. upstream/nodesource. Node.js already ships with a few bundled packages (punycode, npm, etc.). The only issue would be the release schedule; we'd need to decide when a nodemon update/CVE would justify a Node.js package update.
Interesting idea. I can see here that the time needed multiple times for updating the version of nodemon separately for each stream (can be scripted) would be compensated by avoiding the build of nodemon separately. On the other hand, this would go against the default Fedora policy to not bundle and do it only when necessary -- this case does not seem to be necessary.
Honza
nodejs@lists.fedoraproject.org
-
Honza Horak -
Michael Dawson -
Stephen Gallagher