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