* Rebuilding a package after removing a build step @ 2024-09-17 15:59 Konrad Hinsen 2024-09-17 16:27 ` Tobias Geerinckx-Rice 0 siblings, 1 reply; 20+ messages in thread From: Konrad Hinsen @ 2024-09-17 15:59 UTC (permalink / raw) To: Guix Devel Hi everyone, Until today, I thought that all parts of a package definition that could make a difference to the outputs enter somehow into the package hash, such that any relevant change to a package definition causes a rebuild. Today's experience: I built a package, then removed an "add-after" form from "modify-phases", effectively removing a build step, and ran "guix build" again. It built nothing, and returned the same path (same hash) as before. Is this a bug or a feature? If it's a feature, how do I get Guix to rebuild the package after removing a build step? Cheers, Konrad. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Rebuilding a package after removing a build step 2024-09-17 15:59 Rebuilding a package after removing a build step Konrad Hinsen @ 2024-09-17 16:27 ` Tobias Geerinckx-Rice 2024-09-18 8:33 ` Konrad Hinsen 2024-09-18 19:32 ` Felix Lechner via Development of GNU Guix and the GNU System distribution. 0 siblings, 2 replies; 20+ messages in thread From: Tobias Geerinckx-Rice @ 2024-09-17 16:27 UTC (permalink / raw) To: guix-devel, Konrad Hinsen, Guix Devel Hi Konrad, 'That is not possible.' You must somehow not have measured what you thought you measured. Probably not the answer you were looking for, but reassuring in its own way. Can you 'reproduce' this? It might still be enlightening to find out where things went wrong. Kind regards, T G-R Sent on the go. Excuse or enjoy my brevity. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Rebuilding a package after removing a build step 2024-09-17 16:27 ` Tobias Geerinckx-Rice @ 2024-09-18 8:33 ` Konrad Hinsen 2024-09-18 17:40 ` Suhail Singh ` (2 more replies) 2024-09-18 19:32 ` Felix Lechner via Development of GNU Guix and the GNU System distribution. 1 sibling, 3 replies; 20+ messages in thread From: Konrad Hinsen @ 2024-09-18 8:33 UTC (permalink / raw) To: Tobias Geerinckx-Rice, guix-devel Hi Tobias, Geerinckx-Rice <me@tobias.gr> writes: > 'That is not possible.' You must somehow not have measured what you thought you measured. Thanks for restoring my faith in Guix! You were in fact right, I was not measuring what I thought you measured, but for an unusual reason. > Can you 'reproduce' this? It might still be enlightening to find out > where things went wrong. Yes, the behavior is perfectly reproducible. But it was tied to one package definition. I tried modifying a few other definitions, with expected outcomes. So I set out to explore what is special about this package. It's a definition I had started last week and came back to for finishing touches. In the meantime, I had done a "guix pull", and with that update I had retrieved an almost identical definition in the "guix" channel. Someone else had beaten me to submitting the package! Unfortunately, when there are several packages with identical name and version number in two channels, Guix silently chooses one of them. It would probably be more useful to emit a warning. So I ended up editing a package definition which would undergo basic checking by Guile, but then be ignored. Cheers, Konrad. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Rebuilding a package after removing a build step 2024-09-18 8:33 ` Konrad Hinsen @ 2024-09-18 17:40 ` Suhail Singh 2024-09-18 18:27 ` Konrad Hinsen 2024-09-20 17:10 ` Simon Tournier 2024-09-26 13:35 ` Ludovic Courtès 2 siblings, 1 reply; 20+ messages in thread From: Suhail Singh @ 2024-09-18 17:40 UTC (permalink / raw) To: Konrad Hinsen; +Cc: Tobias Geerinckx-Rice, guix-devel Konrad Hinsen <konrad.hinsen@fastmail.net> writes: > Unfortunately, when there are several packages with identical name and > version number in two channels, Guix silently chooses one of them. Ah, I had wondered what it did. Thank you for reporting. > It would probably be more useful to emit a warning. Agreed. On a related note, when multiple channels are enabled, is there a way to specify a specific package from a particular channel? -- Suhail ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Rebuilding a package after removing a build step 2024-09-18 17:40 ` Suhail Singh @ 2024-09-18 18:27 ` Konrad Hinsen 2024-09-19 15:32 ` Suhail Singh 0 siblings, 1 reply; 20+ messages in thread From: Konrad Hinsen @ 2024-09-18 18:27 UTC (permalink / raw) To: Suhail Singh; +Cc: guix-devel Suhail Singh <suhailsingh247@gmail.com> writes: > On a related note, when multiple channels are enabled, is there a way to > specify a specific package from a particular channel? Yes, using the -e option followed by the Guile module name. See https://guix.gnu.org/manual/devel/en/html_node/Invoking-guix-package.html You have to know the module and not just the channel. Cheers, Konrad. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Rebuilding a package after removing a build step 2024-09-18 18:27 ` Konrad Hinsen @ 2024-09-19 15:32 ` Suhail Singh 0 siblings, 0 replies; 20+ messages in thread From: Suhail Singh @ 2024-09-19 15:32 UTC (permalink / raw) To: Konrad Hinsen; +Cc: Suhail Singh, guix-devel Konrad Hinsen <konrad.hinsen@fastmail.net> writes: >> On a related note, when multiple channels are enabled, is there a way to >> specify a specific package from a particular channel? > > Yes, using the -e option followed by the Guile module name. See > > https://guix.gnu.org/manual/devel/en/html_node/Invoking-guix-package.html > > You have to know the module and not just the channel. Thank you for the reference. -- Suhail ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Rebuilding a package after removing a build step 2024-09-18 8:33 ` Konrad Hinsen 2024-09-18 17:40 ` Suhail Singh @ 2024-09-20 17:10 ` Simon Tournier 2024-09-22 8:34 ` Konrad Hinsen 2024-09-26 13:35 ` Ludovic Courtès 2 siblings, 1 reply; 20+ messages in thread From: Simon Tournier @ 2024-09-20 17:10 UTC (permalink / raw) To: Konrad Hinsen, Tobias Geerinckx-Rice, guix-devel Hi Konrad, On mer., 18 sept. 2024 at 10:33, Konrad Hinsen <konrad.hinsen@fastmail.net> wrote: > Unfortunately, when there are several packages with identical name and > version number in two channels, Guix silently chooses one of them. Choose when doing what? :-) When running “guix shell” or “guix package”, it should warn. It doesn’t? Ah? I thought it does… Hum? When packaging, you choose: you use one module or the other, or both. Guile tells you if there is a symbol clash, so then you resolve it by using some #:prefix or #:hide at #:use-module. Else you choose one symbol or the other inside the package definition. Cheers, simon ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Rebuilding a package after removing a build step 2024-09-20 17:10 ` Simon Tournier @ 2024-09-22 8:34 ` Konrad Hinsen 2024-09-22 16:48 ` Kaelyn 0 siblings, 1 reply; 20+ messages in thread From: Konrad Hinsen @ 2024-09-22 8:34 UTC (permalink / raw) To: Simon Tournier, Tobias Geerinckx-Rice, guix-devel Hi Simon, >> Unfortunately, when there are several packages with identical name and >> version number in two channels, Guix silently chooses one of them. > > Choose when doing what? :-) Building, installing, ... whatever you can do with a package. > When running “guix shell” or “guix package”, it should warn. It > doesn’t? Ah? I thought it does… Hum? It doesn't. > When packaging, you choose: you use one module or the other, or both. Right, at the level of Guile code, there is no problem. It's the lookup by name/version at the command line that doesn't let me choose nor tells me that there is a need to choose. Cheers, Konrad. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Rebuilding a package after removing a build step 2024-09-22 8:34 ` Konrad Hinsen @ 2024-09-22 16:48 ` Kaelyn 2024-09-23 8:22 ` Konrad Hinsen 0 siblings, 1 reply; 20+ messages in thread From: Kaelyn @ 2024-09-22 16:48 UTC (permalink / raw) To: Konrad Hinsen; +Cc: Simon Tournier, Tobias Geerinckx-Rice, guix-devel On Sunday, September 22nd, 2024 at 1:34 AM, Konrad Hinsen <konrad.hinsen@fastmail.net> wrote: > > > Hi Simon, > > > > Unfortunately, when there are several packages with identical name and > > > version number in two channels, Guix silently chooses one of them. > > > > Choose when doing what? :-) > > > Building, installing, ... whatever you can do with a package. > > > When running “guix shell” or “guix package”, it should warn. It > > doesn’t? Ah? I thought it does… Hum? > > > It doesn't. Whether it does or doesn't depends on the versions of the duplicate packages in question. If both packages have the same version, then the command line tools will warn about the ambiguous package specification. If the version numbers are different, then the tools will quietly choose the "newer" version (the larger version number). For example, I have a local channel that included an updated version of yt-dlp, and the version in Guix has since been updated to the same version: $ guix package -A yt-dlp yt-dlp 2024.08.06 out local/packages/updated.scm:157:2 yt-dlp 2024.08.06 out gnu/packages/video.scm:3163:2 $ guix build yt-dlp guix build: warning: ambiguous package specification `yt-dlp' guix build: warning: choosing yt-dlp@2024.08.06 from gnu/packages/video.scm:3163:2 But if I change the local version to be different (say the fictitious "2024.09.06"), I no longer get a warning: $ guix build -L ~/guix/local yt-dlp substitute: updating substitutes from... > > > When packaging, you choose: you use one module or the other, or both. > > > Right, at the level of Guile code, there is no problem. It's the lookup > by name/version at the command line that doesn't let me choose nor tells > me that there is a need to choose. Assuming the packages with the same name have different versions, you'd need to specify at least part of the version on the command line to get the older version. In Guix, both GTK+ 2/3 and QT 5/6 are examples where that is needed: $ guix package -A qtbase qtbase 6.6.3 out,debug gnu/packages/qt.scm:716:2 qtbase 5.15.10 out,debug gnu/packages/qt.scm:450:2 $ guix build -n --no-substitutes qtbase The following derivations would be built: /gnu/store/49vfjglgi4myb4c2sa59gjypa3sr05il-qtbase-6.6.3.drv $ guix build -n --no-substitutes qtbase@5 The following derivations would be built: /gnu/store/9bpsq64ljwx2yf1gvw9kby2wda0bcx6a-qtbase-5.15.10.drv However, if there are two packages with the same name and version, then to select a specific one you'd have to use the "-e" flag with a Scheme expression that evaluates to the desired package. Using the previous yt-dlp example, to specify the one in my local channel instead of the one from the guix channel that it warned it was choosing, I'd run: guix build -e '(@ (local packages updated) yt-dlp)' The reason using an expression is needed is because the package specifications like "yt-dlp" or "qtbase@5" are not expressive enough to handle a distinction when the full package name and version--like "yt-dlp@2024.08.06"--match more than one package definition. This also raises a question that I don't think has been asked yet: is the local package you are modifying the same version as the package of the same name in the guix channel? HTH! Cheers, Kaelyn ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Rebuilding a package after removing a build step 2024-09-22 16:48 ` Kaelyn @ 2024-09-23 8:22 ` Konrad Hinsen 2024-09-23 8:42 ` Andreas Enge 2024-09-23 16:27 ` Tobias Geerinckx-Rice 0 siblings, 2 replies; 20+ messages in thread From: Konrad Hinsen @ 2024-09-23 8:22 UTC (permalink / raw) To: Kaelyn; +Cc: Simon Tournier, Tobias Geerinckx-Rice, guix-devel Hi Kaelyn, > Whether it does or doesn't depends on the versions of the duplicate > packages in question. If both packages have the same version, then the > command line tools will warn about the ambiguous package > specification. If the version numbers are different, then the tools > will quietly choose the "newer" version (the larger version number). My case was in neither of these well-defined situations. I had different version number strings without an obvious order relation between them. Not obvious to me at least. Here is an example (edited for focus): $ guix show -L . sbcl-websocket-driver name: sbcl-websocket-driver version: 0.2.0-0.df94496 location: gnu/packages/lisp-xyz.scm:30847:4 name: sbcl-websocket-driver version: 0.2.0-0.17ba553 location: ./kh/packages/lisp.scm:53:4 $ guix build -L . sbcl-websocket-driver /gnu/store/nd9ajz9ni395792f03ggf3jprf44cgz2-sbcl-websocket-driver-0.2.0-0.df94496 There are two definitions for sbcl-websocket-driver, differing only in the commit id. How did "guix build" choose the first one? The second one is newer, but figuring this out requires checking out the repository and analyzing its DAG. It looks like Guix picked the larger one by alphanumeric order, which is not a reasonable choice in a development context. Cheers, Konrad. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Rebuilding a package after removing a build step 2024-09-23 8:22 ` Konrad Hinsen @ 2024-09-23 8:42 ` Andreas Enge 2024-09-23 15:29 ` Konrad Hinsen 2024-09-23 16:03 ` Vagrant Cascadian 2024-09-23 16:27 ` Tobias Geerinckx-Rice 1 sibling, 2 replies; 20+ messages in thread From: Andreas Enge @ 2024-09-23 8:42 UTC (permalink / raw) To: Konrad Hinsen; +Cc: Kaelyn, Simon Tournier, Tobias Geerinckx-Rice, guix-devel Am Mon, Sep 23, 2024 at 10:22:28AM +0200 schrieb Konrad Hinsen: > $ guix show -L . sbcl-websocket-driver > name: sbcl-websocket-driver > version: 0.2.0-0.df94496 > location: gnu/packages/lisp-xyz.scm:30847:4 > It looks like Guix picked the larger one by > alphanumeric order, which is not a reasonable choice in a development > context. This is exactly the role of the number "-0." in front of the git commit; one needs to specify by hand the order of the (non-)releases, as coming from here: (define-public sbcl-websocket-driver (let ((commit "df94496ecb525d086eeada4f5875975515b7212e") (revision "0")) (package (name "sbcl-websocket-driver") (version (git-version "0.2.0" revision commit)) Andreas ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Rebuilding a package after removing a build step 2024-09-23 8:42 ` Andreas Enge @ 2024-09-23 15:29 ` Konrad Hinsen 2024-09-23 16:03 ` Vagrant Cascadian 1 sibling, 0 replies; 20+ messages in thread From: Konrad Hinsen @ 2024-09-23 15:29 UTC (permalink / raw) To: Andreas Enge; +Cc: guix-devel Hi Andreas, >> It looks like Guix picked the larger one by >> alphanumeric order, which is not a reasonable choice in a development >> context. > > This is exactly the role of the number "-0." in front of the git commit; > one needs to specify by hand the order of the (non-)releases, as coming Good to know, thanks! I had been wondering what those revision numbers were good for. Manual ordering looks fine for updating packages in a given channel. But in this case, the two versions come from different channels. It's a bit hard to globally coordinate manual revision numbers across all possible channels! Cheers, Konrad. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Rebuilding a package after removing a build step 2024-09-23 8:42 ` Andreas Enge 2024-09-23 15:29 ` Konrad Hinsen @ 2024-09-23 16:03 ` Vagrant Cascadian 2024-09-23 18:17 ` Suhail Singh 2024-09-24 5:24 ` Konrad Hinsen 1 sibling, 2 replies; 20+ messages in thread From: Vagrant Cascadian @ 2024-09-23 16:03 UTC (permalink / raw) To: Andreas Enge, Konrad Hinsen Cc: Kaelyn, Simon Tournier, Tobias Geerinckx-Rice, guix-devel [-- Attachment #1: Type: text/plain, Size: 1305 bytes --] On 2024-09-23, Andreas Enge wrote: > Am Mon, Sep 23, 2024 at 10:22:28AM +0200 schrieb Konrad Hinsen: >> $ guix show -L . sbcl-websocket-driver >> name: sbcl-websocket-driver >> version: 0.2.0-0.df94496 >> location: gnu/packages/lisp-xyz.scm:30847:4 >> It looks like Guix picked the larger one by >> alphanumeric order, which is not a reasonable choice in a development >> context. > > This is exactly the role of the number "-0." in front of the git commit; > one needs to specify by hand the order of the (non-)releases, as coming > from here: > (define-public sbcl-websocket-driver > (let ((commit "df94496ecb525d086eeada4f5875975515b7212e") > (revision "0")) > (package > (name "sbcl-websocket-driver") > (version (git-version "0.2.0" revision commit)) Rather than picking an arbitrary incremental number, I have in the past used something based on the results from git describe... e.g. in my current checkout of guix: $ git describe --match=v1.4'*' v1.4.0-142685-gfc059c66cf e.g. 142685 commits past v1.4.0, with the commit fc059c66cf That should *usually* end up in the correct order, although sometimes there are surprises. For example, I had to specify --match otherwise it picked v1.3.0 for some inscrutible git merge-ordering reason. live well, vagrant [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 227 bytes --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Rebuilding a package after removing a build step 2024-09-23 16:03 ` Vagrant Cascadian @ 2024-09-23 18:17 ` Suhail Singh 2024-09-24 0:16 ` Kaelyn 2024-09-24 5:24 ` Konrad Hinsen 1 sibling, 1 reply; 20+ messages in thread From: Suhail Singh @ 2024-09-23 18:17 UTC (permalink / raw) To: Vagrant Cascadian Cc: Andreas Enge, Konrad Hinsen, Kaelyn, Simon Tournier, Tobias Geerinckx-Rice, guix-devel Vagrant Cascadian <vagrant@debian.org> writes: > Rather than picking an arbitrary incremental number, I have in the past > used something based on the results from git describe... e.g. in my > current checkout of guix: > > $ git describe --match=v1.4'*' > v1.4.0-142685-gfc059c66cf > > e.g. 142685 commits past v1.4.0, with the commit fc059c66cf > > That should *usually* end up in the correct order, although sometimes > there are surprises. For example, I had to specify --match otherwise it > picked v1.3.0 for some inscrutible git merge-ordering reason. That seems like a useful and fairly generally applicable strategy. Any reason as to why something like that (which allows for additional optional arguments such as "--match-v1.4'*'") shouldn't be used as the default (as opposed to manual revision numbers)? -- Suhail ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Rebuilding a package after removing a build step 2024-09-23 18:17 ` Suhail Singh @ 2024-09-24 0:16 ` Kaelyn 0 siblings, 0 replies; 20+ messages in thread From: Kaelyn @ 2024-09-24 0:16 UTC (permalink / raw) To: Suhail Singh Cc: Vagrant Cascadian, Andreas Enge, Konrad Hinsen, Simon Tournier, Tobias Geerinckx-Rice, guix-devel On Monday, September 23rd, 2024 at 11:17 AM, Suhail Singh <suhailsingh247@gmail.com> wrote: > > > Vagrant Cascadian vagrant@debian.org writes: > > > Rather than picking an arbitrary incremental number, I have in the past > > used something based on the results from git describe... e.g. in my > > current checkout of guix: > > > > $ git describe --match=v1.4'*' > > v1.4.0-142685-gfc059c66cf > > > > e.g. 142685 commits past v1.4.0, with the commit fc059c66cf > > > > That should usually end up in the correct order, although sometimes > > there are surprises. For example, I had to specify --match otherwise it > > picked v1.3.0 for some inscrutible git merge-ordering reason. > > > That seems like a useful and fairly generally applicable strategy. Any > reason as to why something like that (which allows for additional > optional arguments such as "--match-v1.4'*'") shouldn't be used as the > default (as opposed to manual revision numbers)? There are a few problems with using that as the default: * Generating that version number requires the git source repository; a package definition requires a fixed version number that can be computed without ever downloading the source code, since it is part of the package metadata (though such a strategy could potentially be used by e.g. "guix refresh -u" though that would require a consistent way of setting the revision in the package definition such that the tool knows what string to change). * Using something like "git describe" to compute the revision would either be specific to packages which are built from git checkouts (i.e. built into the git-version function) or recipes for obtaining similar output would have to be written for the other version control systems for which support is desired. Closely related (but optional if the actual value of the revision is treated more loosely) is that some packages would need the "--match" flag to generate revision numbers from the correct point and the match expression would have to be updated when the "base" version for the revision counting changes. * Within git repos, "git describe" only works if there are (annotated) tags for "git describe" to base the revision number on. If the source repo doesn't use tags, the approach won't work and manual revision numbers would still be needed. Likewise, if the repo doesn't use annotated tags or uses annotated tags for purposes other than tagging official releases, the chosen tag used for the revision (even at a given commit, if an older commit is given a new tag) may not be consistent without using a sufficiently specific "--match" flag. I also want to say that the above points are primarily about automatically using "git describe" to dynamically generate a revision. I do not want to rule out or discourage ideas for ways to make use of "git describe" more convenient as a source of truth when determining what value to use for the revision. I think it could be quite useful especially for updating packages or doing local development. Cheers, Kaelyn > > -- > Suhail ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Rebuilding a package after removing a build step 2024-09-23 16:03 ` Vagrant Cascadian 2024-09-23 18:17 ` Suhail Singh @ 2024-09-24 5:24 ` Konrad Hinsen 1 sibling, 0 replies; 20+ messages in thread From: Konrad Hinsen @ 2024-09-24 5:24 UTC (permalink / raw) To: Vagrant Cascadian, Andreas Enge Cc: Kaelyn, Simon Tournier, Tobias Geerinckx-Rice, guix-devel Hi Vagrant, > Rather than picking an arbitrary incremental number, I have in the past > used something based on the results from git describe... e.g. in my > current checkout of guix: > > $ git describe --match=v1.4'*' > v1.4.0-142685-gfc059c66cf > > e.g. 142685 commits past v1.4.0, with the commit fc059c66cf That looks very good! Not suitable for automation, as Kaelyn explained, but it could be codified as a recommendation for developers. Possibly with tool support for package developers, e.g. "guix derive-revision". Cheers, Konrad. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Rebuilding a package after removing a build step 2024-09-23 8:22 ` Konrad Hinsen 2024-09-23 8:42 ` Andreas Enge @ 2024-09-23 16:27 ` Tobias Geerinckx-Rice 1 sibling, 0 replies; 20+ messages in thread From: Tobias Geerinckx-Rice @ 2024-09-23 16:27 UTC (permalink / raw) To: Konrad Hinsen; +Cc: Kaelyn, Simon Tournier, guix-devel While others have pointed out the workflow fix, On 2024-09-23 10:22, Konrad Hinsen wrote: >> If both packages have the same version, then the >> command line tools will warn about the ambiguous package >> specification. If the version numbers are different, then the tools >> will quietly choose the "newer" version (the larger version number). > > My case was in neither of these well-defined situations. It was. The second. This behaviour is stable and documented, at least under (guix)Invoking guix package, although it applies to the entire CLI. Kind regards, T G-R Sent from a Web browser. Excuse or enjoy my brevity. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Rebuilding a package after removing a build step 2024-09-18 8:33 ` Konrad Hinsen 2024-09-18 17:40 ` Suhail Singh 2024-09-20 17:10 ` Simon Tournier @ 2024-09-26 13:35 ` Ludovic Courtès 2024-09-30 14:25 ` Konrad Hinsen 2 siblings, 1 reply; 20+ messages in thread From: Ludovic Courtès @ 2024-09-26 13:35 UTC (permalink / raw) To: Konrad Hinsen; +Cc: Tobias Geerinckx-Rice, guix-devel Hi, Konrad Hinsen <konrad.hinsen@fastmail.net> skribis: > Unfortunately, when there are several packages with identical name and > version number in two channels, Guix silently chooses one of them. > It would probably be more useful to emit a warning. I believe that’s already the case. Specifically, if there are several packages with the same name and different versions, the newest one is picked up: --8<---------------cut here---------------start------------->8--- $ guix build gcc-toolchain -n /gnu/store/9h8cbavj4q7pq1590xsnjw71ww0d06gk-gcc-toolchain-14.2.0-debug /gnu/store/x2kv3zw2k7ql211m5kvb6yw401gab0x9-gcc-toolchain-14.2.0 /gnu/store/9h5kczcvfxs2fgn9708cs70xi0xpjrw6-gcc-toolchain-14.2.0-static --8<---------------cut here---------------end--------------->8--- When there are several matching packages with the given name and version, you get a warning: --8<---------------cut here---------------start------------->8--- $ guix build guile@2.2 -n guix build: warning: ambiguous package specification `guile@2.2' guix build: warning: choosing guile@2.2.7 from gnu/packages/guile.scm:287:2 The following files would be downloaded: /gnu/store/3qj7zmfq5cw5k37zf8qz9dr4kld8rsnd-guile-2.2.7-debug /gnu/store/0g5cbaf3xczis6x11j3h2xc1x1dpp3xk-guile-2.2.7 --8<---------------cut here---------------end--------------->8--- In Guix itself, there are no packages with the exact same name/version pair though. The example above is because there’s 2.2.7 and 2.2.4. Ludo’. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Rebuilding a package after removing a build step 2024-09-26 13:35 ` Ludovic Courtès @ 2024-09-30 14:25 ` Konrad Hinsen 0 siblings, 0 replies; 20+ messages in thread From: Konrad Hinsen @ 2024-09-30 14:25 UTC (permalink / raw) To: Ludovic Courtès; +Cc: Tobias Geerinckx-Rice, guix-devel Hi Ludo, >> Unfortunately, when there are several packages with identical name and >> version number in two channels, Guix silently chooses one of them. >> It would probably be more useful to emit a warning. > > I believe that’s already the case. We already had some discussion, the conclusion being that there are indeed tests for equal and for "higher" version, but that these tests do not always correspond to the intention of "choosing the newest version". In particular, Guix uses version *strings* rather than version *numbers*, with alphabetical ordering for the non-numerical parts of these strings. In the common case of version strings containing git commit hashes, alphabetical order does not correspond to "newest version". So you can consider yourself safe when working on the most recent commit of a package, and yet end up building a older but alphabetically higher version from another channel. Andreas pointed out that this is the reason for adding a manually curated revision number before such hashes. But there is no coordination mechanism for such revision number across channels. Vagrant suggested deriving a version number from the commit history using "git describe". That sounds like a good solution, but it's not used in Guix as far as I can tell. Cheers, Konrad. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Rebuilding a package after removing a build step 2024-09-17 16:27 ` Tobias Geerinckx-Rice 2024-09-18 8:33 ` Konrad Hinsen @ 2024-09-18 19:32 ` Felix Lechner via Development of GNU Guix and the GNU System distribution. 1 sibling, 0 replies; 20+ messages in thread From: Felix Lechner via Development of GNU Guix and the GNU System distribution. @ 2024-09-18 19:32 UTC (permalink / raw) To: Tobias Geerinckx-Rice, guix-devel, Konrad Hinsen, Guix Devel Hi, On Tue, Sep 17 2024, Tobias Geerinckx-Rice wrote: > 'That is not possible.' I believe I experienced it when removing or adding propagated or native inputs (not sure) to my very own guile-pam [1] while using 'guix shell'. Unfortunately, I have not had time to investigate. Kind regards Felix [1] https://issues.guix.gnu.org/72316 P.S. Please excuse or enjoy my brevity. ^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2024-09-30 14:26 UTC | newest] Thread overview: 20+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2024-09-17 15:59 Rebuilding a package after removing a build step Konrad Hinsen 2024-09-17 16:27 ` Tobias Geerinckx-Rice 2024-09-18 8:33 ` Konrad Hinsen 2024-09-18 17:40 ` Suhail Singh 2024-09-18 18:27 ` Konrad Hinsen 2024-09-19 15:32 ` Suhail Singh 2024-09-20 17:10 ` Simon Tournier 2024-09-22 8:34 ` Konrad Hinsen 2024-09-22 16:48 ` Kaelyn 2024-09-23 8:22 ` Konrad Hinsen 2024-09-23 8:42 ` Andreas Enge 2024-09-23 15:29 ` Konrad Hinsen 2024-09-23 16:03 ` Vagrant Cascadian 2024-09-23 18:17 ` Suhail Singh 2024-09-24 0:16 ` Kaelyn 2024-09-24 5:24 ` Konrad Hinsen 2024-09-23 16:27 ` Tobias Geerinckx-Rice 2024-09-26 13:35 ` Ludovic Courtès 2024-09-30 14:25 ` Konrad Hinsen 2024-09-18 19:32 ` Felix Lechner via Development of GNU Guix and the GNU System distribution.
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.