On Wed, Aug 9, 2023 at 10:07 AM Honza Horak <[email protected]> wrote:
> On Tue, Aug 8, 2023 at 4:20 PM Stephen Gallagher <[email protected]> > wrote: > >> 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) >> >> > 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 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
