On Thu, Apr 14, 2022 at 5:43 AM Zuzana Svetlikova <zsvetlik(a)redhat.com> wrote:
Hi.
I see your point, but is this really *needed*?
Has anyone ever complained about ugly release field, or is this just a cosmetic thing?
I've heard complaints, but that aspect *is* mostly cosmetic. By doing
this, I'll also be able to switch to %autorelease for both Node.js and
NPM, which is a benefit to packaging simplicity (and makes merge
requests to dist-git less prone to needing a rebase).
Does npm being a separate package or being part of nodejs matter when
it comes to npm modules parallel-instalable?
Yes, because it allows us to keep a single version of NPM irrespective
of the version of Node.js being used. (Current NPM releases support
Node.js 12+, which is the same set of versions we support).
As for Node.js, I'm actually going to end up de-modularizing it in
Fedora. I've figured out how to make it work so that Node.js can be
made parallel-installable as nodejs12, nodejs14, nodejs16, etc.
packages (with an appropriate one providing the default
`/usr/bin/node` for each release).
Won't this cause discrepancies and give us more work when it
comes to updates? I believe that was one of the main reasons why we merged npm into
nodejs.
No, the main reason we merged npm into nodejs was because it predated
the current bundling policy for Fedora and Node.js had an exception
granted for it. It was too hard to keep NPM up to date back then
because we were packaging all of its dependencies individually (and
they were generally not compatible with other packages in the distro).
Now that we have the current bundling policy, we are free to maintain
it separately. In the general case, I plan to ship whatever version is
shipped with the latest stable release of Node.js. The only reason I
am packaging 8.6.0 in this request is because I can only drop the
release field nonsense during a version number increase (otherwise it
breaks the update path). In future updates, I'll track whatever
version is most compatible with the supported stable versions of
Node.js. (For example, when 18.0.0 releases next week, if it's
carrying an NPM package that has dropped support for Node.js 12, I'll
wait to package that version until Node.js 12.x goes EOL on the 30th
unless a CVE forces my hand.)
Also, do you plan on shipping npm as a dnf module or rpm?
RPM, not module. The same will also become true of the existing
Node.js modules: they'll be converted to non-modular packages.