Re: [INPUT REQUESTED] Re: F38 proposal: Node.js Repackaging (Self-Contained Change proposal)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




Dne 07. 10. 22 v 20:54 Stephen Gallagher napsal(a):
On Tue, Sep 6, 2022 at 2:29 PM Ben Cotton <bcotton@xxxxxxxxxx> wrote:
https://fedoraproject.org/wiki/Changes/NodejsRepackaging

This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.

== Summary ==
We are reworking the Node.js packaging to make Node.js versions
available as parallel-installable packages.
So, I'd like to give an update here and address potential issues that
I discovered this week surrounding the upgrade path.

First and most exciting: I've got the packaging work for Node.js 16
and Node.js 18 in good shape and it can be tried out by using my COPR
at https://copr.fedorainfracloud.org/coprs/sgallagh/nodejs-alternatives/
(`dnf copr enable sgallagh/nodejs-alternatives`) on x86_64 systems.
Thanks to the input of folks on this thread, I've now put together
parallel-installable versions, any of which can provide the
/usr/bin/node by installing the appropriate
`nodejsXX-interpreter-default` package. I've also got the dependencies
established in such a way that a fresh install of `dnf install nodejs`
on releases will result in automatically installing the latest stable
version that was available at the Fedora release's Beta Freeze. (So
for F38 it will be Node.js 18, for F39 it will be Node.js 20).

On upgrade from Fedora 37 (which has nodejs == 18.x) to Fedora 38, the
nodejs18 package will Obsolete the nodejs package. On upgrade of the
same system to Fedora 39 later, it will continue on the Node.js 18
package. To switch to the newer version, the user will need to
manually run `dnf swap nodejs18-interpreter-default
nodejs20-interpreter-default). While this may seem unexpected
behavior, I feel that it's better to maintain compatibility on upgrade
with any applications in use rather than to force the upgrade unless
the current version is going out of support.

When a Node.js release goes out of support, we have a question to
answer: do we Obsolete it with a newer version? If so, which one? The
most recent version or the oldest one? It will not be 100% compatible
in either case. Do we Obsolete it with fedora-retired-packages? Do we
just leave the packages in Fedora forever (possibly patching the
`/usr/bin/node` binary to warn that it's out of support)?


If you kept nonversioned rolling nodejs package, which would be the default, you would not have the issues with upgrade. And if somebody installed the versioned package, then it would be up to the user to take action.

I would strongly suggest against introducing the versioned packages. It never made anything good for Fedora. If you want to keep providing some version for backward compatibility, so be it, add the versioned package. But don't do that by default.


Vít


There's another potential upgrade issue: We have multiple choices of
how to upgrade from the nodejs package to the nodejsXX packages:
1) Upgrading from either F36 or F37 will result in you getting Node.js
18. (This method is closest to how things worked prior to this Change,
where the nodejs package would just get updated to the latest stable
release)
2) Upgrading from F36 will move you onto nodejs16 in F38. Upgrading
from F37 will move you onto Node.js 18 in F38. (This method maintains
compatibility with applications running on the current system)
3) Upgrading from F36 or F37 will *remove* the nodejs package and the
user will need to manually select one to install. (This method has
increased friction, but more user choice)
4) Upgrading from F36 or F37 will leave the existing nodejs package on
the system, receiving no updates. Users of F38 will need to manually
remove and install a newer version. (This method is high-friction,
offers nothing over any of the others and potentially leaves people
vulnerable)

With options 1), 3) and 4), we can make the change in F38 exclusively.
However if we want to do 2), we *also* need to either backport this
Change to Fedora 37 and Fedora 36 because otherwise we would have to
continuously update the Obsoletes: values in F38. With 1) I can update
the Obsoletes: to just treat any Node.js with an epoch < 3 as the
trigger to move to nodejs18.

My questions to those brave souls who have read this far:
1) Which do you think is the best of the above options for upgrades to F38?
2) What do we do about future upgrades in the following scenarios:
     a. The user has nodejsXX installed as the default interpreter. The
nodejsXX package is no longer available upon upgrade (EOL).
     b. The user has nodejsXX installed as the default interpreter. The
nodejsXX package is available but non-default upon upgrade.

Thank you for reading to the end.
_______________________________________________
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

Attachment: OpenPGP_signature
Description: OpenPGP digital signature

_______________________________________________
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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux