* bug#60200: Incompatibilities between gcc-toolchain and R packages @ 2022-12-19 12:00 Lars-Dominik Braun 2022-12-19 23:32 ` zimoun 0 siblings, 1 reply; 9+ messages in thread From: Lars-Dominik Braun @ 2022-12-19 12:00 UTC (permalink / raw) To: 60200 Hi, I ran into issues with the package r-brms. Take the following reproducer as an example: $ guix shell r-brms r make sed gcc-toolchain bash -C --no-cwd --share=/tmp $ R > library(brms) > fit1 <- brm(count ~ zAge + zBase * Trt + (1|patient), data = epilepsy, family = poisson()) Compiling Stan program... Error in dyn.load(libLFile) : unable to load shared object '/tmp/RtmpKqzbYg/file3245e787c.so': /gnu/store/vqhamsanmlm8v6f90a635zc6gmhwlphp-gfortran-10.3.0-lib/lib/libstdc++.so.6: version `GLIBCXX_3.4.29' not found (required by /tmp/RtmpKqzbYg/file3245e787c.so) Error in sink(type = "output") : invalid connection The same code works well with gcc-toolchain@10 instead of gcc-toolchain (@12, which is the default). As we can see the generated shared library above depends on GCC 12, 10 and GFortran 10 at the same time: $ ldd /tmp/RtmpKqzbYg/file3245e787c.so | grep -e gcc -e fortran libstdc++.so.6 => /gnu/store/4zvswpr2h3b7dvqpvjcdam8vfhyjrmgl-gcc-12.2.0-lib/lib/libstdc++.so.6 (0x00007f69bd9fc000) libgcc_s.so.1 => /gnu/store/4zvswpr2h3b7dvqpvjcdam8vfhyjrmgl-gcc-12.2.0-lib/lib/libgcc_s.so.1 (0x00007f69bd898000) libgfortran.so.5 => /gnu/store/vqhamsanmlm8v6f90a635zc6gmhwlphp-gfortran-10.3.0-lib/lib/libgfortran.so.5 (0x00007f69bd3e6000) libquadmath.so.0 => /gnu/store/094bbaq6glba86h1d4cj16xhdi6fk2jl-gcc-10.3.0-lib/lib/libquadmath.so.0 (0x00007f69bd39b000) libgomp.so.1 => /gnu/store/094bbaq6glba86h1d4cj16xhdi6fk2jl-gcc-10.3.0-lib/lib/libgomp.so.1 (0x00007f69bccf9000) The command used to link that .so is revealed by strace to be (filenames are random and may differ between runs): ["g++", "-std=gnu++14", "-shared", "-L/gnu/store/145dmr8drw3yzrdhzbsksi05p599hrs6-r-minimal-4.2.2/lib/R/lib", "-L/usr/local/lib", "-o", "file3373276d0.so", "file3373276d0.o", "/gnu/store/5rdg6sv1nrg1ikqxcykvdh9g4yd2xjvy-r-rstan-2.21.7/site-library/rstan/lib//libStanServices.a", "-L/gnu/store/y7rvp47mz3hcnpvnqsx42qz5yvs10pnl-r-stanheaders-2.21.0-7/site-library/StanHeaders/lib/", "-lStanHeaders", "-L/gnu/store/01lhjrrkvrnsjd8xh4ssdn3bgxc422jl-r-rcppparallel-5.1.5/site-library/RcppParallel/lib/", "-ltbb", "-L/gnu/store/145dmr8drw3yzrdhzbsksi05p599hrs6-r-minimal-4.2.2/lib/R/lib", "-lR"] So it links against libStanServices.a, libStanHeaders(.a), libtbb(.so) and libR(.so) of which only libR has a reference to gfortran: $ ldd /gnu/store/145dmr8drw3yzrdhzbsksi05p599hrs6-r-minimal-4.2.2/lib/R/lib/libR.so | grep -i fortran libgfortran.so.5 => /gnu/store/vqhamsanmlm8v6f90a635zc6gmhwlphp-gfortran-10.3.0-lib/lib/libgfortran.so.5 (0x00007f5be49db000) That means every software linking against R is also incompatible with the current default gcc-toolchain (when using the command line or specifications; different story when writing package recipes). Possible solutions: - Make gcc-toolchain@10 the default and rename gcc-toolchain@12 to gcc-toolchain-next@12, like we do for Haskell and (sometimes) Python. - Update, both, the default GCC and GFortran to version 12. - Explicitly depend on the correct gcc-toolchain in packages that need a compiler. Cheers, Lars ^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#60200: Incompatibilities between gcc-toolchain and R packages 2022-12-19 12:00 bug#60200: Incompatibilities between gcc-toolchain and R packages Lars-Dominik Braun @ 2022-12-19 23:32 ` zimoun 2022-12-21 9:24 ` Lars-Dominik Braun 0 siblings, 1 reply; 9+ messages in thread From: zimoun @ 2022-12-19 23:32 UTC (permalink / raw) To: Lars-Dominik Braun, 60200 Hi Lars, On Mon, 19 Dec 2022 at 13:00, Lars-Dominik Braun <lars@6xq.net> wrote: > $ guix shell r-brms r make sed gcc-toolchain bash -C --no-cwd --share=/tmp > $ R > > library(brms) > > fit1 <- brm(count ~ zAge + zBase * Trt + (1|patient), data = epilepsy, family = poisson()) > Compiling Stan program... > Error in dyn.load(libLFile) : > unable to load shared object '/tmp/RtmpKqzbYg/file3245e787c.so': > /gnu/store/vqhamsanmlm8v6f90a635zc6gmhwlphp-gfortran-10.3.0-lib/lib/libstdc++.so.6: version `GLIBCXX_3.4.29' not found (required by /tmp/RtmpKqzbYg/file3245e787c.so) > Error in sink(type = "output") : invalid connection > > The same code works well with gcc-toolchain@10 instead of gcc-toolchain > (@12, which is the default). As we can see the generated shared library > above depends on GCC 12, 10 and GFortran 10 at the same time: [...] > Possible solutions: > > - Make gcc-toolchain@10 the default and rename gcc-toolchain@12 to > gcc-toolchain-next@12, like we do for Haskell and (sometimes) Python. > - Update, both, the default GCC and GFortran to version 12. > - Explicitly depend on the correct gcc-toolchain in packages that need > a compiler. It depends on what you are naming default. :-) The default GCC toolchain for compiling is provided by the package gcc-toolchain@10. Without any specification about the version, if a package name is defined at several versions, then the command-line uses the higher version of this package. To avoid the kind of confusing error as you are observing, usually, the suffix ’-next’ is applied to the package name for higher versions. For instance, python-numpy-next. To add a data point to the confusion, consider the package ’gcc’ instead of ’gcc-toolchain’. As noticed earlier [1], there is a bug. Consider: --8<---------------cut here---------------start------------->8--- $ guix show gcc@6 guix show: error: gcc@6: package not found $ guix show gcc@7 name: gcc version: 7.5.0 outputs: + lib: shared libraries + debug: debug information + out: everything else systems: x86_64-linux i686-linux dependencies: gmp@6.2.1 isl@0.23 libelf@0.8.13 libstdc++-headers@10.3.0 mpc@1.2.1 mpfr@4.1.0 perl@5.34.0 texinfo@6.7 zlib@1.2.11 location: gnu/packages/gcc.scm:601:2 homepage: https://gcc.gnu.org/ license: GPL 3+ synopsis: GNU Compiler Collection description: GCC is the GNU Compiler Collection. It provides compiler front-ends for several languages, including C, C++, Objective-C, Fortran, Ada, and + Go. It also includes runtime support libraries for these languages. --8<---------------cut here---------------end--------------->8--- It is because the ’properties’ field of gcc@7 is rewritten, --8<---------------cut here---------------start------------->8--- (define-public gcc-7 (package (inherit gcc-6) (version "7.5.0") [...] (properties `((compiler-cpu-architectures ("aarch64" ,@%gcc-7.5-aarch64-micro-architectures) ("armhf" ,@%gcc-7.5-armhf-micro-architectures) ("x86_64" ,@%gcc-7.5-x86_64-micro-architectures)))))) --8<---------------cut here---------------end--------------->8--- and thus, it looses ’hidden’, as shown here: --8<---------------cut here---------------start------------->8--- $ guix repl GNU Guile 3.0.8 Copyright (C) 1995-2021 Free Software Foundation, Inc. Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'. This program is free software, and you are welcome to redistribute it under certain conditions; type `,show c' for details. Enter `,help' for help. scheme@(guix-user)> ,use(gnu packages gcc) scheme@(guix-user)> (package-properties gcc-6) $1 = ((hidden? . #t) (gcc-libc . #f)) scheme@(guix-user)> (package-properties gcc-7) $2 = ((compiler-cpu-architectures ("aarch64" "armv8-a" "armv8.1-a" "armv8.2-a" "armv8.3-a") ("armhf" "armv7" "armv7-a" "armv7-m" "armv7-r" "armv7e-m" "armv7ve" "armv8-a" "armv8-a+crc" "armv8.1-a" "armv8.1-a+crc" "armv8-m.base" "armv8-m.main" "armv8-m.main+dsp" "iwmmxt" "iwmmxt2") ("x86_64" "core2" "nehalem" "westmere" "sandybridge" "ivybridge" "haswell" "broadwell" "skylake" "bonnell" "silvermont" "knl" "skylake-avx512" "k8" "k8-sse3" "barcelona" "bdver1" "bdver2" "bdver3" "bdver4" "znver1" "btver1" "btver2" "geode"))) scheme@(guix-user)> --8<---------------cut here---------------end--------------->8--- Because the intent of, --8<---------------cut here---------------start------------->8--- (define-public gcc-toolchain-aka-gcc ;; It's natural for users to try "guix install gcc". This package ;; automatically "redirects" them to 'gcc-toolchain'. (deprecated-package "gcc" gcc-toolchain-10)) --8<---------------cut here---------------end--------------->8--- is to return the default GCC toolchain when typing ’gcc’ at the command line. And error for any other version than @10. 1: <https://yhetil.org/guix/87h6yz46wp.fsf@gmail.com> Update the default GCC toolchain from 10 to 12 is a core-updates change and a (almost) full world rebuild. When the issue you are describing is an issue about an inconsistency with the command-line. From my point of view, an option would to rename the packages gcc-toolchain@11 and gcc-toolchain@12 as gcc-toolchain-next@11 and gcc-toolchain-next@12. Which would be consistent with the rest. And also fix the bug with the package ’gcc’. :-) Cheers, simon ^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#60200: Incompatibilities between gcc-toolchain and R packages 2022-12-19 23:32 ` zimoun @ 2022-12-21 9:24 ` Lars-Dominik Braun 2023-01-11 21:13 ` properties for default version? (was bug#60200: Incompatibilities between gcc-toolchain and R packages) Simon Tournier 0 siblings, 1 reply; 9+ messages in thread From: Lars-Dominik Braun @ 2022-12-21 9:24 UTC (permalink / raw) To: zimoun; +Cc: 60200 [-- Attachment #1: Type: text/plain, Size: 827 bytes --] Hi Simon, > Without any specification about the version, if a package name is > defined at several versions, then the command-line uses the higher > version of this package. minor nit-pick: Not the command-line, but everything that uses specifications. So manifests via SPECIFICATIONS->MANIFEST are also affected, see: (use-modules (gnu packages) (guix profiles)) (manifest-entries (specifications->manifest '("gcc-toolchain"))) $2 = (#<<manifest-entry> name: "gcc-toolchain" version: "12.2.0" …) The -next suffix has the obvious disadvantage that specifications may become invalid as we move -next to the “regular” package. So maybe marking packages “default” like the attached patch does could improve the current situation. Not just for gcc, but also Haskell and Python come to mind. Cheers, Lars [-- Attachment #2: default-gcc-toolchain.patch --] [-- Type: text/plain, Size: 2317 bytes --] diff --git a/gnu/packages.scm b/gnu/packages.scm index 61345f75a9..7e5a6d49c2 100644 --- a/gnu/packages.scm +++ b/gnu/packages.scm @@ -356,20 +356,24 @@ (define cache (find-packages-by-name/direct name version)))) (define (find-best-packages-by-name name version) - "If version is #f, return the list of packages named NAME with the highest -version numbers; otherwise, return the list of packages named NAME and at -VERSION." + "If version is #f, return the list of packages named NAME with only +packages marked default? or, if none exist, the highest version numbers; +otherwise, return the list of packages named NAME and at VERSION." (if version (find-packages-by-name name version) (match (find-packages-by-name name) (() '()) ((matches ...) - ;; Return the subset of MATCHES with the higher version number. - (let ((highest (package-version (first matches)))) - (take-while (lambda (p) - (string=? (package-version p) highest)) - matches)))))) + ;; Return the subset of MATCHES which are marked default or those with + ;; the higher version number. + (let ((highest (package-version (first matches))) + (default (filter (lambda (p) (assoc-ref (package-properties p) 'default?)) matches))) + (if (not (null? default)) + default + (take-while (lambda (p) + (string=? (package-version p) highest)) + matches))))))) ;; Prevent Guile 3 from inlining this procedure so we can mock it in tests. (set! find-best-packages-by-name find-best-packages-by-name) diff --git a/gnu/packages/commencement.scm b/gnu/packages/commencement.scm index b4566b41cc..2d5e0add26 100644 --- a/gnu/packages/commencement.scm +++ b/gnu/packages/commencement.scm @@ -3855,7 +3855,10 @@ (define* (make-gcc-toolchain gcc ("libc-static" ,libc "static")))))) (define-public gcc-toolchain - (make-gcc-toolchain gcc-final)) + (let ((parent (make-gcc-toolchain gcc-final))) + (package + (inherit parent) + (properties (alist-cons 'default? #t (package-properties parent)))))) (define-public gcc-toolchain-4.8 (make-gcc-toolchain gcc-4.8)) ^ permalink raw reply related [flat|nested] 9+ messages in thread
* properties for default version? (was bug#60200: Incompatibilities between gcc-toolchain and R packages) 2022-12-21 9:24 ` Lars-Dominik Braun @ 2023-01-11 21:13 ` Simon Tournier 2023-01-12 6:22 ` Csepp ` (2 more replies) 0 siblings, 3 replies; 9+ messages in thread From: Simon Tournier @ 2023-01-11 21:13 UTC (permalink / raw) To: Guix Devel; +Cc: Lars-Dominik Braun [-- Attachment #1: Type: text/plain, Size: 1570 bytes --] Hi, As bug#60200 [1], the issue is one that many of us often hit: packages with several versions and when the highest one is not the default. Other said, build systems use some version for compiler and tools but Guix can also offer more recent versions for these very same compilers and tools. It leads to the issue when selecting the name of a compiler or tool (command line or manifest). The user does not get the ones used as default by build system. In addition to [1], another example: --8<---------------cut here---------------start------------->8--- $ guix shell ocaml ocaml-ppxlib -- ocaml --version The OCaml toplevel, version 5.0.0 --8<---------------cut here---------------end--------------->8--- But the OCaml libraries are built using OCaml compiler v4.14, thus it leads to error as: --8<---------------cut here---------------start------------->8--- Error: /gnu/store/vglxlc8riynj1g937clvwv8yg40lln6z-profile/lib/ocaml/site-lib/ppxlib/ppxlib.cmi is not a compiled interface for this version of OCaml. It seems to be for an older version of OCaml. --8<---------------cut here---------------end--------------->8--- For other cases, such issue is avoided by appending the suffix -next to package name; as with ghc-next, python-numpy-next, emacs-next, etc. Personally, I find the -next trick useful because the package name reflects that it is not the default. However, it can be annoying to update manifest files when this -next is becoming default. Well, what do people think about this Lars’s patch? [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: patch --] [-- Type: text/x-diff, Size: 2317 bytes --] diff --git a/gnu/packages.scm b/gnu/packages.scm index 61345f75a9..7e5a6d49c2 100644 --- a/gnu/packages.scm +++ b/gnu/packages.scm @@ -356,20 +356,24 @@ (define cache (find-packages-by-name/direct name version)))) (define (find-best-packages-by-name name version) - "If version is #f, return the list of packages named NAME with the highest -version numbers; otherwise, return the list of packages named NAME and at -VERSION." + "If version is #f, return the list of packages named NAME with only +packages marked default? or, if none exist, the highest version numbers; +otherwise, return the list of packages named NAME and at VERSION." (if version (find-packages-by-name name version) (match (find-packages-by-name name) (() '()) ((matches ...) - ;; Return the subset of MATCHES with the higher version number. - (let ((highest (package-version (first matches)))) - (take-while (lambda (p) - (string=? (package-version p) highest)) - matches)))))) + ;; Return the subset of MATCHES which are marked default or those with + ;; the higher version number. + (let ((highest (package-version (first matches))) + (default (filter (lambda (p) (assoc-ref (package-properties p) 'default?)) matches))) + (if (not (null? default)) + default + (take-while (lambda (p) + (string=? (package-version p) highest)) + matches))))))) ;; Prevent Guile 3 from inlining this procedure so we can mock it in tests. (set! find-best-packages-by-name find-best-packages-by-name) diff --git a/gnu/packages/commencement.scm b/gnu/packages/commencement.scm index b4566b41cc..2d5e0add26 100644 --- a/gnu/packages/commencement.scm +++ b/gnu/packages/commencement.scm @@ -3855,7 +3855,10 @@ (define* (make-gcc-toolchain gcc ("libc-static" ,libc "static")))))) (define-public gcc-toolchain - (make-gcc-toolchain gcc-final)) + (let ((parent (make-gcc-toolchain gcc-final))) + (package + (inherit parent) + (properties (alist-cons 'default? #t (package-properties parent)))))) (define-public gcc-toolchain-4.8 (make-gcc-toolchain gcc-4.8)) [-- Attachment #3: Type: text/plain, Size: 87 bytes --] 1: <http://issues.guix.gnu.org/msgid/Y6BSQpbK7BgW5Idk@noor.fritz.box> Cheers, simon ^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: properties for default version? (was bug#60200: Incompatibilities between gcc-toolchain and R packages) 2023-01-11 21:13 ` properties for default version? (was bug#60200: Incompatibilities between gcc-toolchain and R packages) Simon Tournier @ 2023-01-12 6:22 ` Csepp 2023-01-12 9:03 ` pukkamustard 2023-01-17 16:09 ` Ludovic Courtès 2 siblings, 0 replies; 9+ messages in thread From: Csepp @ 2023-01-12 6:22 UTC (permalink / raw) To: Simon Tournier; +Cc: Lars-Dominik Braun, guix-devel Simon Tournier <zimon.toutoune@gmail.com> writes: > Hi, > > As bug#60200 [1], the issue is one that many of us often hit: packages > with several versions and when the highest one is not the default. > > Other said, build systems use some version for compiler and tools but > Guix can also offer more recent versions for these very same compilers > and tools. It leads to the issue when selecting the name of a compiler > or tool (command line or manifest). The user does not get the ones used > as default by build system. > > In addition to [1], another example: > > $ guix shell ocaml ocaml-ppxlib -- ocaml --version > The OCaml toplevel, version 5.0.0 > > > But the OCaml libraries are built using OCaml compiler v4.14, thus it > leads to error as: > > Error: /gnu/store/vglxlc8riynj1g937clvwv8yg40lln6z-profile/lib/ocaml/site-lib/ppxlib/ppxlib.cmi > is not a compiled interface for this version of OCaml. > It seems to be for an older version of OCaml. > > For other cases, such issue is avoided by appending the suffix -next to > package name; as with ghc-next, python-numpy-next, emacs-next, etc. > > Personally, I find the -next trick useful because the package name > reflects that it is not the default. However, it can be annoying to > update manifest files when this -next is becoming default. > > Well, what do people think about this Lars’s patch? As I *just* ran into some OCaml and GCC related issues a few days ago, I'm in favor of either the default flag or expanding the -next suffix naming convention to more packages. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: properties for default version? (was bug#60200: Incompatibilities between gcc-toolchain and R packages) 2023-01-11 21:13 ` properties for default version? (was bug#60200: Incompatibilities between gcc-toolchain and R packages) Simon Tournier 2023-01-12 6:22 ` Csepp @ 2023-01-12 9:03 ` pukkamustard 2023-01-17 16:09 ` Ludovic Courtès 2 siblings, 0 replies; 9+ messages in thread From: pukkamustard @ 2023-01-12 9:03 UTC (permalink / raw) To: Simon Tournier; +Cc: Lars-Dominik Braun, guix-devel Simon Tournier <zimon.toutoune@gmail.com> writes: > $ guix shell ocaml ocaml-ppxlib -- ocaml --version > The OCaml toplevel, version 5.0.0 I also encountered this and was surprised. > Personally, I find the -next trick useful because the package name > reflects that it is not the default. However, it can be annoying to > update manifest files when this -next is becoming default. > > Well, what do people think about this Lars’s patch? I like it. I think adding the `default?` property is nicer than the -next trick. Only nitpick: I would maybe call the property `default-version?` to make meaning of the property more explicit. Cheers, pukkamustard ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: properties for default version? (was bug#60200: Incompatibilities between gcc-toolchain and R packages) 2023-01-11 21:13 ` properties for default version? (was bug#60200: Incompatibilities between gcc-toolchain and R packages) Simon Tournier 2023-01-12 6:22 ` Csepp 2023-01-12 9:03 ` pukkamustard @ 2023-01-17 16:09 ` Ludovic Courtès 2023-01-17 18:41 ` Felix Lechner via Development of GNU Guix and the GNU System distribution. 2023-01-17 18:48 ` Simon Tournier 2 siblings, 2 replies; 9+ messages in thread From: Ludovic Courtès @ 2023-01-17 16:09 UTC (permalink / raw) To: Simon Tournier; +Cc: Guix Devel, Lars-Dominik Braun Hello, Simon Tournier <zimon.toutoune@gmail.com> skribis: > Other said, build systems use some version for compiler and tools but > Guix can also offer more recent versions for these very same compilers > and tools. It leads to the issue when selecting the name of a compiler > or tool (command line or manifest). The user does not get the ones used > as default by build system. > > In addition to [1], another example: > > $ guix shell ocaml ocaml-ppxlib -- ocaml --version > The OCaml toplevel, version 5.0.0 > > > But the OCaml libraries are built using OCaml compiler v4.14, thus it > leads to error as: > > Error: /gnu/store/vglxlc8riynj1g937clvwv8yg40lln6z-profile/lib/ocaml/site-lib/ppxlib/ppxlib.cmi > is not a compiled interface for this version of OCaml. > It seems to be for an older version of OCaml. > > For other cases, such issue is avoided by appending the suffix -next to > package name; as with ghc-next, python-numpy-next, emacs-next, etc. > > Personally, I find the -next trick useful because the package name > reflects that it is not the default. However, it can be annoying to > update manifest files when this -next is becoming default. To me it’s mostly a packaging issue: I would expect ‘ocaml’ to be able to use ‘ocaml-ppxlib’. If not, then it should indeed be ‘-next’. > Well, what do people think about this Lars’s patch? > > diff --git a/gnu/packages.scm b/gnu/packages.scm > index 61345f75a9..7e5a6d49c2 100644 > --- a/gnu/packages.scm > +++ b/gnu/packages.scm > @@ -356,20 +356,24 @@ (define cache > (find-packages-by-name/direct name version)))) > > (define (find-best-packages-by-name name version) > - "If version is #f, return the list of packages named NAME with the highest > -version numbers; otherwise, return the list of packages named NAME and at > -VERSION." > + "If version is #f, return the list of packages named NAME with only > +packages marked default? or, if none exist, the highest version numbers; > +otherwise, return the list of packages named NAME and at VERSION." > (if version > (find-packages-by-name name version) > (match (find-packages-by-name name) > (() > '()) > ((matches ...) > - ;; Return the subset of MATCHES with the higher version number. > - (let ((highest (package-version (first matches)))) > - (take-while (lambda (p) > - (string=? (package-version p) highest)) > - matches)))))) > + ;; Return the subset of MATCHES which are marked default or those with > + ;; the higher version number. > + (let ((highest (package-version (first matches))) > + (default (filter (lambda (p) (assoc-ref (package-properties p) 'default?)) matches))) > + (if (not (null? default)) > + default > + (take-while (lambda (p) > + (string=? (package-version p) highest)) > + matches))))))) I’m slightly reluctant because then you can have several packages that declare themselves as “default”, which looks weird. Reasoning about why a given package was chosen would now involve more than version strings. Thoughts? Ludo’. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: properties for default version? (was bug#60200: Incompatibilities between gcc-toolchain and R packages) 2023-01-17 16:09 ` Ludovic Courtès @ 2023-01-17 18:41 ` Felix Lechner via Development of GNU Guix and the GNU System distribution. 2023-01-17 18:48 ` Simon Tournier 1 sibling, 0 replies; 9+ messages in thread From: Felix Lechner via Development of GNU Guix and the GNU System distribution. @ 2023-01-17 18:41 UTC (permalink / raw) To: Ludovic Courtès; +Cc: Simon Tournier, Guix Devel, Lars-Dominik Braun Hi, Ludovic Courtès <ludo@gnu.org> writes: > Thoughts? What if package variables in Guix were functions that accepted an optional argument? Each function could deliver any available version or a default, possibly accompanied by a warning when the wanted version was not available. Kind regards Felix Lechner ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: properties for default version? (was bug#60200: Incompatibilities between gcc-toolchain and R packages) 2023-01-17 16:09 ` Ludovic Courtès 2023-01-17 18:41 ` Felix Lechner via Development of GNU Guix and the GNU System distribution. @ 2023-01-17 18:48 ` Simon Tournier 1 sibling, 0 replies; 9+ messages in thread From: Simon Tournier @ 2023-01-17 18:48 UTC (permalink / raw) To: Ludovic Courtès; +Cc: Guix Devel, Lars-Dominik Braun Hi Ludo, On mar., 17 janv. 2023 at 17:09, Ludovic Courtès <ludo@gnu.org> wrote: >> For other cases, such issue is avoided by appending the suffix -next to >> package name; as with ghc-next, python-numpy-next, emacs-next, etc. >> >> Personally, I find the -next trick useful because the package name >> reflects that it is not the default. However, it can be annoying to >> update manifest files when this -next is becoming default. > > To me it’s mostly a packaging issue: I would expect ‘ocaml’ to be able > to use ‘ocaml-ppxlib’. If not, then it should indeed be ‘-next’. Currently, yes it is a packaging issue. And yes, the usual trick to fix the issue is to append -next to the package name. As I have tried to explain in bug#60200 [1]. ;-) About this -next, Lars’s answer is, quoting [2]: The -next suffix has the obvious disadvantage that specifications may become invalid as we move -next to the “regular” package. So maybe marking packages “default” like the attached patch does could improve the current situation. Not just for gcc, but also Haskell and Python come to mind. Hence this discussion. :-) The addition of a ’properties’ to make the difference between “current” and “next” packages appears to be a cleaner fix than to append -next to package name. Consider the manifest: (specifications->manifest (list "ghc-next@9.2")) and note that currently the Haskell compiler used by haskell-build-system is ghc@8.10.7. When this default is updated to an higher version of GHC, says version 9.4, then this manifest breaks because ghc-next@9.2 is renamed ghc@9.2; the -next suffix is only applied to version higher than the one used by the Haskell build system. 1: <http://issues.guix.gnu.org/msgid/86wn6nynp1.fsf@gmail.com> 2: <http://issues.guix.gnu.org/msgid/Y6LQs9+in964glaz@noor.fritz.box> > I’m slightly reluctant because then you can have several packages that > declare themselves as “default”, which looks weird. Reasoning about why > a given package was chosen would now involve more than version strings. As similarly we can have several packages that declare themselves with the same name and version. :-) If we go for -next, then the two packages gcc-toolchain@{11,12} must be renamed gcc-toolchain-next@{11,12} to be compliant and fixes bug#60200. Why a given package was chosen as “default”? Because the packages marked as “default” are – if and only if several versions are publicly declared – the ones used by the build-systems and also the ones with many dependents as Numpy. It avoids the -next dance. Well, all in all this “default” property appears to me more elegant than append -next to package name. Cheers, simon ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2023-01-17 19:12 UTC | newest] Thread overview: 9+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2022-12-19 12:00 bug#60200: Incompatibilities between gcc-toolchain and R packages Lars-Dominik Braun 2022-12-19 23:32 ` zimoun 2022-12-21 9:24 ` Lars-Dominik Braun 2023-01-11 21:13 ` properties for default version? (was bug#60200: Incompatibilities between gcc-toolchain and R packages) Simon Tournier 2023-01-12 6:22 ` Csepp 2023-01-12 9:03 ` pukkamustard 2023-01-17 16:09 ` Ludovic Courtès 2023-01-17 18:41 ` Felix Lechner via Development of GNU Guix and the GNU System distribution. 2023-01-17 18:48 ` Simon Tournier
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/guix.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.