On Mon, Sep 12, 2022 at 3:34 PM Miro HronĨok <mhroncok(a)redhat.com> wrote:
...
I don't like the EOL-Obsolte within one Fedora release. Things
like this should
only change on release boundary. Other than that it sounds good, but consider
that packages requiring /usr/bin/node might pick any of the versions we ship.
Something might need to Suggest the one we prefer.
Yeah, I think we'd do `Suggests: <whatever is the latest stable at
Fedora Beta>`.
In Python, we deliberately decided that RPM-packaged software only
uses one
version at one particular Fedora release. Do you wish to support RPMs to use
arbitrary versions including "doesn't matter"?
The reality of the ecosystem is that many applications lag in their
support for stable Node.js releases by months. So I think I'd want us
to be able to package FooApp that relies on Node.js 16 even if the
"default" for the release is Node.js 18. This should require that they
modify the RPM packaged application to explicitly look for
/usr/bin/node-16, rather than /usr/bin/node. Thinking about it more, I
think we'd probably want to have *all* applications pin to their
preferred Node.js runtime and reserve /usr/bin/node for developer
convenience.
It does beg the question of what to do with an application that adds
support for a newer Node.js runtime mid-Fedora-lifecycle. Do we
require them to stick with the initial interpreter for the life of
that release to avoid pulling in another runtime on upgrade, or do we
allow them to jump to the newer version?
Depending on the answer of that questions, I might give more
suggestions
inspired by Python, or think about how to do it differently.