[Top][All Lists]

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

bug#22017: closed (Pinning a Guix version)

From: GNU bug Tracking System
Subject: bug#22017: closed (Pinning a Guix version)
Date: Thu, 28 Nov 2019 10:54:01 +0000

Your message dated Thu, 28 Nov 2019 11:53:40 +0100
with message-id <address@hidden>
and subject line Re: Bug #22017 Hunting: Pinning a Guix version
has caused the debbugs.gnu.org bug report #22017,
regarding Pinning a Guix version
to be marked as done.

(If you believe you have received this mail in error, please contact

22017: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=22017
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- Subject: Pinning a Guix version Date: Thu, 26 Nov 2015 14:30:55 +0100 User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

In some cases, it’s useful to be able to pin a particular Guix version
and to use that version (see the RepPar paper for some examples.)

A naive way to do that is:

  git clone …/guix.git my-pinned-guix
  (cd my-pinned-guix; git checkout deadbeef)
  guix package -L my-pinned-guix --manifest=my-manifest.scm

However, this is currently broken for several reasons:

  1. ‘fold-packages’ recursively traverses ‘my-pinned-guix’ for .scm
     files, and on its way it finds build-aux/build-self.scm,
     tests/*.scm, and emacs/*.scm, which breaks it all.  These
     directories have to be explicitly removed before we can do

     Internally, ‘%package-module-path’ can have entries that are pairs
     and where the cdr restricts the search of .scm files to a
     sub-directory.  We should expose that facility to -L and
     ‘GUIX_PACKAGE_PATH’ using some special syntax.

     That way, one could do (say):

       guix package -L my-pinned-guix,gnu/packages

     meaning that only the ‘gnu/packages’ sub-directory is searched.

     OTOH, it may be advisable to use the (guix …) modules from
     ‘my-pinned-guix’ and not just the (gnu packages …) modules, because
     the former obviously contribute to the final result.

  2. The ‘gnu/packages/patches’ sub-directory is not automatically added
     to the search path, so in fact one has to run:

       guix package -L my-pinned-guix \
         -L my-pinned-guix/gnu/packages/patches …
     so that patches are found.  Not convenient.

  3. When doing so, we get loads of:

     ;;; note: source file /tmp/guix/guix/build/perl-build-system.scm
     ;;;       newer than compiled 

     We should silence Guile.

  4. Related to #1: since everything is evaluated, this is ~10 times
     slower than the normal thing.

I think ‘guix pull’ would be a good place to add support for tagging
Guixes and similar, but it would be good if the naive approach above
would work just as well.


--- End Message ---
--- Begin Message --- Subject: Re: Bug #22017 Hunting: Pinning a Guix version Date: Thu, 28 Nov 2019 11:53:40 +0100
On Thu, 28 Nov 2019 at 09:34, Ludovic Courtès <address@hidden> wrote:

> Yes, I think we should close this issue and create a new one about
> tagging Guix revisions/channel instances.

done. :-)

--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]