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:
>>
>> 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.

 

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