Add guidelines for using different nodejs versions #1561
No reviewers
Labels
No labels
announce
bootstrap
Closed As
accepted
Closed As
duplicate
Closed As
exceptionexpired
Closed As
fixed
Closed As
invalid
Closed As
nothingtodo
Closed As
permanentexception
Closed As
rejected
Closed As
temporaryexception
Closed As
wontfix
cmake
committee
draftneeded
hasdraft
meeting
meson
needinfo
Priority
In Committee
Priority
Needs Review
Priority
Waiting For Reporter
rust
writeup
No milestone
No project
No assignees
3 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
packaging/guidelines!1561
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "jstanek/packaging-guidelines:nodejs-metapackage"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This is aiming to summarize how we envision the various packaged nodejs streams should be used once the metapackage change lands.
It is expected that the section might grow or be adjusted as we gather feedback from the wider user base after the change lands; this is intended to be a usable starting point.
I provided a couple of nitpicks.
Could you please also provide some runtime dependency examples? I worry, for example, about how I should deal with nodejs shebangs.
@ -16,3 +16,3 @@* The name of a Node.js extension/library package must start with _nodejs-_ then the upstream name or name used in the npm registry. For example: _nodejs-foomodule_. While it is uncommon for a package's name to contain _node_, if it does, you should still add the nodejs prefix. For instance, the npm registry contains a _uuid_ and a _node-uuid_ module, which would need to be named _nodejs-uuid_ and _nodejs-node-uuid_, respectively.== BuildRequires== Managing versioned stream dependenciesI'm not keen on the usage of "stream" in this context. RHEL uses that vocabulary. Modularity did. But I don't think we use it elsewhere in the packaging guidelines.
Yeah, since I also think of this in terms of the distributions that are based on Fedora, the "stream" comes to me naturally; but I'm open to changes. Suggestions? „Managing dependencies to specific nodejs versions"?
@ -19,0 +18,4 @@== Managing versioned stream dependenciesIn Fedora, multiple Node.js versions are generally available at any given time.You should take that into an account when specifying dependencies for your package.into account or into consideration . Either way, drop the an, please. (For some reason, I don't see a way to add a direct change suggestion here :/ )
@ -19,0 +20,4 @@In Fedora, multiple Node.js versions are generally available at any given time.You should take that into an account when specifying dependencies for your package.If your package could be used with any currently supported major version of Node.js,This seems problematic. How do I recognize that this is the case? Also, for rawhide, does this mean any version of Node.js supported in the 18-month future, not only currently?
That is good question, and unfortunately I don't have enough javascript packaging experience to be able to answer this with certainty. My guess would be to take a look at the
engines.nodefield inpackage.jsonfile and be guided by that. But ideally test that.Now that I think about it, yes. We will be changing what the default/recommended version will be in rawhide periodically, and the package should ideally survive that without a rebuild.
The idea of this paragraph is to avoid overspecification of the dependencies. For packages that are simple enough and do not depend on the latest-greatest new features of Node, and can be packaged with anything, I would prefer to not have to specify e.g.
Buildrequires: nodejs22-develand then having to rebuild it whennodejs22will become EOL.How to actually tell this is the case will require some testing on the packager side, most likely.
@ -19,0 +21,4 @@You should take that into an account when specifying dependencies for your package.If your package could be used with any currently supported major version of Node.js,it is recommended to use the generic `+nodejs+` package and/or it's subpackages.Please replace is recommended with a guideline (e.g. you SHOULD or the package SHOULD).
Please replace use with an actual packaging term (e.g. require).
@ -19,0 +22,4 @@If your package could be used with any currently supported major version of Node.js,it is recommended to use the generic `+nodejs+` package and/or it's subpackages.This will provide one of the supported major versions;provide is also hard to parse here. This will ensure the package is installable with... or something along those lines sounds better to me.
@ -19,0 +23,4 @@If your package could be used with any currently supported major version of Node.js,it is recommended to use the generic `+nodejs+` package and/or it's subpackages.This will provide one of the supported major versions;however, the exact version might be different in different Fedora versions.Or depending on other installed packages?
Not really.
Require: nodejsorBuildRequire: nodejswill pull the same version in every installation of given Fedora version (e.g. in current rawhide,nodejsrequiresnodejs22). But that requirement will be changing, usually in rawhide somewhere safe-ish between branching of new releases, so in time it may look similarly to this:nodejsrequiresnodejs22nodejsrequiresnodejs24nodejsrequiresnodejs26So if you build the same package across multiple releases, you may be building against different nodejs version in each of them.
Oh, I assumed the dependency could be satisfied with any nodejs version. That is no longer the case?
Technically speaking, no, it's no longer the case. In case you specify just
BuildRequires: nodejs, you are handing control over which major version you'll get to the maintainers of that package (us). We want to have more control over which package would be "selected" by that requirement.If all of the streams would just
Provides: nodejs = <version>, then the choice would be up to DNF, and generally speaking always the latest available stream. That is not always what we want.@ -19,0 +25,4 @@This will provide one of the supported major versions;however, the exact version might be different in different Fedora versions.If you know that your package will only work with a subset of the currently supported Node.js versions (or even a single one),Where can I find the list of supported Node.js versions in the current Fedora release?
EDIT: I see this is answered later in the text. How can we make that more obvious here?
I'll try to think about how can I move things around here.
@ -19,0 +26,4 @@however, the exact version might be different in different Fedora versions.If you know that your package will only work with a subset of the currently supported Node.js versions (or even a single one),you should pick one of them and request it specifically.request -> require
@ -23,6 +37,22 @@ To build a package that is a nodejs module, bundles or uses nodejs modules, or nBuildRequires: nodejs-devel....If the package only builds against specific version(s) of Node.js, request the specific version:I'd rather split this into two sentences:
@ -26,0 +47,4 @@For example:....$ sudo dnf --repo=rawhide repoquery --whatprovides 'alternative-for(nodejs-devel)'No need for sudo
@churchyard wrote in #1561 (comment):
Runtime is a bit of different beast, and the problem space is unfortunately still open. But I'll will add something.
Shebangs could (and probably) should be adjusted if you need the specific version at runtime, but that is not something we have any support (scripts, macros) for now. So I guess in the meantime, I'll add something to the effect of „You MUST
Require: nodejsXY-binif you need a specific version at runtime. This will unfortunately make your package incompatible with any other package that requires different nodejsXY version.“ Perhaps invitation for collaboration will also not go amiss there.Add guidelines for using different nodejs versionsto WIP: Add guidelines for using different nodejs versions@churchyard I've attempted to incorporate your feedback, and expanded the text with (hopefully) answers to your questions. Let me know what you think of the next iterations.
I plan to just add commits new commits as feedback comes, and I'll squash them before merging the final version. Hence the WIP prefix in order to not merge the messy history.
e7cc02f337to761008346c@ -19,0 +44,4 @@If you know that your package will only work with a subset of the currently supported Node.js versions (or even a single one),you should pick one of them and require it specifically.Use the `+nodejs{XY}+` package (e.g. `+nodejs24+` for Node.js v24.x.y) for this.At this place, I would highly encourage to work with upstream of such package to relax the restriction. Also, it would be good idea to document why the restriction applies so it is easier to revisit.
@ -23,6 +54,39 @@ To build a package that is a nodejs module, bundles or uses nodejs modules, or nBuildRequires: nodejs-devel....If the package only builds against a specific version of Node.js, BuildRequire it explicitly.This could somehow refer to the comment above.
@ -26,0 +71,4 @@....# This package requires /usr/bin/node to launch Node.js v24.x or any newerRequires: alternative-for(nodejs-bin) >= 24Would e.g.
Recommendsbe an option here? Of course the question is if it is better option to have something possibly broken or to have e.g. broken update (maybe preventing system updates and therefore security)I don't think so. The entire point of this
Requires:line is to specify "I absolutely need at least Node.js 24 as/usr/bin/nodeor I will not work". WithRecommends:, that would be only a suggestion; and if you don't really need a specific version, this requirement should not be there at all.No further feedback in a week; marking this as ready to be merged.
e0f255a0cftodb2c28b047WIP: Add guidelines for using different nodejs versionsto Add guidelines for using different nodejs versionsdb2c28b047to89684f5787Squashed "incorporating feedback" commits to the original one.
View command line instructions
Checkout
From your project repository, check out a new branch and test the changes.Merge
Merge the changes and update on Forgejo.Warning: The "Autodetect manual merge" setting is not enabled for this repository, you will have to mark this pull request as manually merged afterwards.