| Message ID | 145389012.1197903.1642777885519@privateemail.com |
|---|---|
| State | New |
| Headers | show |
| Series | [bug#53414] update Node LTS to 16.13.2 | expand |
| Context | Check | Description |
|---|---|---|
| cbaines/applying patch | fail | View Laminar job |
| cbaines/issue | success | View issue |
This works for me, though i'd prefer it wouldn't replace the previous LTS version as it hasn't reached end of life https://nodejs.org/en/about/releases/
code@ceephax.com schreef op wo 23-02-2022 om 13:13 [+0000]: > This works for me, though i'd prefer it wouldn't replace the previous LTS version > as it hasn't reached end of life https://nodejs.org/en/about/releases/ It will be end-of-life in two months. More generally, I don't see the appeal of packaging old versions, especially old versions that will soon be unsupported, when there are newer versions (16.X.Y) that will be supported for a relatively long time (two years). Also, a question for zamfofex: do the existing node packages still build, or are there (new) build failures after the patch? Greetings, Maxime.
On Fri, 25 Feb 2022, at 11:07, Maxime Devos wrote: > code@ceephax.com schreef op wo 23-02-2022 om 13:13 [+0000]: >> This works for me, though i'd prefer it wouldn't replace the previous LTS version >> as it hasn't reached end of life https://nodejs.org/en/about/releases/ > > It will be end-of-life in two months. More generally, I don't see the End of life is 2023-04-30 > appeal of packaging old versions, especially old versions that will > soon be unsupported, when there are newer versions (16.X.Y) that will > be supported for a relatively long time (two years). > > Also, a question for zamfofex: do the existing node packages still > build, or are there (new) build failures after the patch? > > Greetings, > Maxime. > > Attachments: > * signature.asc
code@ceephax.com schreef op vr 25-02-2022 om 11:24 [+0000]: > It will be end-of-life in two months. More generally, I don't see > the End of life is 2023-04-30 I looked at the wrong version (v12 instead of v14), it's a year and two months instead of two months. Still, the latest LTS (v16) seems better to me since it is newer and will be supported for longer. Greetings, Maxime.
> Still, the latest LTS (v16) seems better to me since it is newer and will be > supported for longer. with packages like nodejs one often needs both older and newer versions in parallel to also be able to build projects that haven't been ported to the new nodejs. note that this supersedes https://issues.guix.gnu.org/48396 (i don't know what is the right way to record that fact in debbugs, besides this note). -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “Everything is interesting if you go into it *deeply* enough.” — Richard Feynman (1918–1988)
Attila Lendvai schreef op vr 25-02-2022 om 13:09 [+0000]: > > Still, the latest LTS (v16) seems better to me since it is newer > > and will be > > supported for longer. > > with packages like nodejs one often needs both older and newer > versions in > parallel to also be able to build projects that haven't been ported > to the new > nodejs. Ignoring bootstrapping, this does not seem to be the case so far in Guix -- the only results of "git grep -F \#\:node gnu" is # 7 lines gnu/packages/node.scm: `(#:node ,node-bootstrap so it seems that, except for bootstrapping, a single version of 'node' suffices. If it turns out that some packages still require v14, then we can discuss that upstream, patch the package and/or introduce a 'node-14' package variant, like we do with, say, autoconf, bcftools and gcc. Actually 'gcc' does not point to the latest version, but to the slightly older 10.3.0, but that's only due to core-updates concerns and perhaps because upstream does -Werror too often. And 'autoconf' is not autoconf-2.71 because ‘this is the renaissance version, which is not widelt supported yet’. But AFAICT, there are no compatibility concerns with v14->v16. Greetings, Maxime.
Hi all, Maxime Devos <maximedevos@telenet.be> writes: > [[PGP Signed Part:Undecided]] > Attila Lendvai schreef op vr 25-02-2022 om 13:09 [+0000]: >> > Still, the latest LTS (v16) seems better to me since it is newer >> > and will be >> > supported for longer. >> >> with packages like nodejs one often needs both older and newer >> versions in >> parallel to also be able to build projects that haven't been ported >> to the new >> nodejs. > > Ignoring bootstrapping, this does not seem to be the case so far in > Guix -- the only results of "git grep -F \#\:node gnu" is > > # 7 lines > gnu/packages/node.scm: `(#:node ,node-bootstrap > > so it seems that, except for bootstrapping, a single version of 'node' > suffices. If I may shime in, I agree that it's best to have fewer versions of node for Guix's own node packages, however for end-users I think it's a good idea to provide multiple versions they can install. I am not a web developper so if anybody knows better please correct me :-), but I think it's common for a website projects to depend on a specific supported LTS version of node. For example, one time I contributed to a project that recommended using a "node version manager" script, https://github.com/nvm-sh/nvm, to easily switch between node versions for different project. This script seems pretty popular, but it downloads official binaries :-/, Guix provides much better tools to do this by default. So I'm thinking it might make Guix more appealing to web developpers if we provided multiple versions of node, only the LTS releases though I'd say. For nodejs applications packaged in Guix though, I agree we don't want multiple versions. Thanks, Pierre
Pierre Langlois schreef op vr 25-02-2022 om 16:31 [+0000]: > If I may shime in, I agree that it's best to have fewer versions of > node > for Guix's own node packages, however for end-users I think it's a > good > idea to provide multiple versions they can install. I'm not opposed to including multiple LTS versions, as long as they are supported upstream, there actual users of the old LTS versions and there is some reason to use older versions (perhaps there are a few incompatibilities?). However, I would prefer the latest version to be standard version (with variable name node-lts) so node packages in Guix use the latest LTS by default. Something like (define-public node-lts (package (inherit node) (version "16.13.2") [...])) ;; Older LTS versions, still maintained upstream and used (see <...>). ;; There are some incompatibilities between [...], so allow users ;; to choose which node to use. (define-public node-14 (package (inherit node-lts) (version "14.[...]") [...])) Greetings, Maxime.
From 63d2976a063da9c710ec09f7ebf7158777c134d6 Mon Sep 17 00:00:00 2001 From: zamfofex <zamfofex@twdb.moe> Date: Fri, 21 Jan 2022 12:06:08 -0300 Subject: [PATCH] gnu: node-lts: Update to 16.13.2 * gnu/packages/node.scm (node-lts): Update to 16.13.2. --- gnu/packages/node.scm | 42 ++++++++++++++++++++---------------------- 1 file changed, 20 insertions(+), 22 deletions(-) diff --git a/gnu/packages/node.scm b/gnu/packages/node.scm index 6b543ac..941174e 100644 --- a/gnu/packages/node.scm +++ b/gnu/packages/node.scm @@ -10,6 +10,7 @@ ;;; Copyright © 2020 Ricardo Wurmus <rekado@elephly.net> ;;; Copyright © 2021 Simon Tournier <zimon.toutoune@gmail.com> ;;; Copyright © 2021 Guillaume Le Vaillant <glv@posteo.net> +;;; Copyright © 2022 zamfofex <zamfofex@twdb.moe> ;;; ;;; This file is part of GNU Guix. ;;; @@ -570,7 +571,7 @@ (define-public node-llparse-bootstrap (define-public llhttp-bootstrap (package (name "llhttp") - (version "2.1.4") + (version "6.0.6") (source (origin (method git-fetch) (uri (git-reference @@ -579,8 +580,7 @@ (define-public llhttp-bootstrap (file-name (git-file-name name version)) (sha256 (base32 - "115mwyds9655p76lhglxg2blc1ksgrix6zhigaxnc2q6syy3pa6x")) - (patches (search-patches "llhttp-bootstrap-CVE-2020-8287.patch")) + "1c1p39m46frpslm5yx13hj58r7s0cila03yvqp6caip5dbizpfmr")) (modules '((guix build utils))) (snippet '(begin @@ -618,10 +618,13 @@ (define-public llhttp-bootstrap (add-after 'install 'install-src (lambda* (#:key outputs #:allow-other-keys) (let* ((out (assoc-ref outputs "out")) - (src-dir (string-append out "/src"))) - (install-file "build/c/llhttp.c" src-dir) - (install-file "src/native/api.c" src-dir) - (install-file "src/native/http.c" src-dir) + (src-dir (string-append out "/src")) + (src-src-dir (string-append src-dir "/src"))) + (install-file "src/llhttp.gyp" src-dir) + (install-file "src/common.gypi" src-dir) + (install-file "build/c/llhttp.c" src-src-dir) + (install-file "src/native/http.c" src-src-dir) + (install-file "src/native/api.c" src-src-dir) #t)))))) (native-inputs `(("esbuild" ,esbuild) @@ -640,14 +643,14 @@ (define-public llhttp-bootstrap (define-public node-lts (package (inherit node) - (version "14.18.1") + (version "16.13.2") (source (origin (method url-fetch) (uri (string-append "https://nodejs.org/dist/v" version "/node-v" version ".tar.xz")) (sha256 (base32 - "1vc9rypkgr5i5y946jnyr9jjpydxvm74p1s17rg2zayzvlddg89z")) + "185lm13q0kwz0qimc38c7mxn8ml6m713pjdjsa9jna9az4gxxccq")) (modules '((guix build utils))) (snippet `(begin @@ -751,6 +754,7 @@ (define-public node-lts "lib/internal/v8_prof_polyfill.js" "test/parallel/test-child-process-spawnsync-shell.js" "test/parallel/test-fs-write-sigxfsz.js" + "test/parallel/test-stdin-from-file-spawn.js" "test/parallel/test-stdio-closed.js" "test/sequential/test-child-process-emfile.js") (("'/bin/sh'") @@ -767,8 +771,8 @@ (define-public node-lts ;; FIXME: These tests fail in the build container, but they don't ;; seem to be indicative of real problems in practice. (for-each delete-file - '("test/parallel/test-cluster-master-error.js" - "test/parallel/test-cluster-master-kill.js")) + '("test/parallel/test-cluster-primary-error.js" + "test/parallel/test-cluster-primary-kill.js")) ;; These require a DNS resolver. (for-each delete-file @@ -805,20 +809,14 @@ (define-public node-lts "test/parallel/test-tls-server-verify.js")) ;; Replace pre-generated llhttp sources - (let ((llhttp (assoc-ref inputs "llhttp"))) - (copy-file (string-append llhttp "/src/llhttp.c") - "deps/llhttp/src/llhttp.c") - (copy-file (string-append llhttp "/src/api.c") - "deps/llhttp/src/api.c") - (copy-file (string-append llhttp "/src/http.c") - "deps/llhttp/src/http.c") - (copy-file (string-append llhttp "/include/llhttp.h") - "deps/llhttp/include/llhttp.h")))))))) + (delete-file-recursively "deps/llhttp") + (copy-recursively (string-append (assoc-ref inputs "llhttp") "/src") + "deps/llhttp"))))))) (native-inputs (list ;; Runtime dependencies for binaries used as a bootstrap. c-ares-for-node brotli - icu4c-67 + icu4c libuv-for-node `(,nghttp2 "lib") openssl @@ -833,7 +831,7 @@ (define-public node-lts (list bash coreutils c-ares-for-node - icu4c-67 + icu4c libuv-for-node llhttp-bootstrap brotli base-commit: 80194d9e47f9f50602a5a97ecd33fb9a95dfe03d -- 2.34.0