On 12. 09. 22 20:56, Stephen Gallagher wrote:
On Wed, Sep 7, 2022 at 3:30 PM Miro Hrončok <mhroncok@xxxxxxxxxx> wrote:
On 07. 09. 22 19:30, Neal Gompa wrote:
That said, I don't think alternatives makes sense for this case.
Me neither. We used this for /usr/bin/python3 in RHEL 8 and it's very bad UX
and requires custom hacks in scriptlets even in RHEL 9 to undo it. It's ugly
and hard to get rid of.
See https://docs.fedoraproject.org/en-US/packaging-guidelines/Alternatives/
"""
Alternatives MAY be used to allow parallel installation of software when:
the software can be used as a drop-in replacement and functions with
sufficient similarity that users and other programs would, within reason, not
need to know which variant is currently installed
"""
Not exactly the case here.
"""
AND
the selection of the software is only performed system-wide by the system
administrator and end users do not have a need to switch between the variants.
"""
Not exactly the case here either.
Happy to talk to you about other options next week. Just noting this now here
fast before I leave for a conference for the rest of this week.
I was thinking about this some more and I have a modified proposal
that I'd like to suggest. It will be much the same as the original,
but with the following changes:
* We will stop shipping an independent `npm` subpackage and ship
/usr/bin/npm-$NODE_VERSION in the `nodejs-$NODE_VERSION` package.
* Instead of the `update-alternatives` system, each
`nodejs-$NODE_VERSION` still in support will ship a
`nodejs-$NODE_VERSION-default` subpackage that will conflict with
other packages that `Provides: nodejs-default`. It will provide the
/usr/bin/node and /usr/bin/npm symlinks to the matching $NODE_VERSION
* When a particular version of Node.js goes out of support before the
EOL of that Fedora release, we will have the main
`nodejs-$NODE_VERSION` subpackage add `Obsoletes:
nodejs-$NODE_VERSION-default < <this_release>`. We will still ship the
`-default` subpackage, but it will have to be reinstalled
intentionally once the EOL is reached.[1]
The general idea here would be to allow end-users to pick whichever
installed version they want to own /usr/bin/node and /usr/bin/npm, as
well as binding those two executables tightly together[2]. In
addition, it would offer us an opportunity to be noisy about the EOL
date. The downside to this, of course, is that it could be annoying to
our users that they need to take manual action to remain on an EOL
Node.js version (as /usr/bin/node).
WDYT?
[1] If we want to be more picky, we could change the subpackage to
`-eol-default` rather than just `-default` once the EOL is reached, in
addition to adding the `Obsoletes:` to the main package.
[2] The `npm update -g npm` command will still allow this to be overridden.
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.
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"?
Depending on the answer of that questions, I might give more suggestions
inspired by Python, or think about how to do it differently.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
