On Tue, Aug 8, 2023 at 10:09 AM Honza Horak <[email protected]> wrote: > > On Tue, Aug 8, 2023 at 3:18 PM Stephen Gallagher <[email protected]> wrote: >> >> On Thu, Jul 13, 2023 at 10:36 AM Michael Dawson <[email protected]> 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 <[email protected]> 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 <[email protected]> >> >> 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 <[email protected]> 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) > > > 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. _______________________________________________ nodejs mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
