bug-guix
[Top][All Lists]
Advanced

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

Re: [PATCH] guix refresh: Add '--key-download'.


From: Ludovic Courtès
Subject: Re: [PATCH] guix refresh: Add '--key-download'.
Date: Sat, 08 Jun 2013 16:48:51 +0200
User-agent: Gnus/5.130007 (Ma Gnus v0.7) Emacs/24.3 (gnu/linux)

Nikita Karetnikov <address@hidden> skribis:

>> It just occurred to me that it might be more intuitive to use one of
>
>>   'interactive
>>   #f   ; never download
>>   _    ; (any other value) always download
>
> IMO, an attached version is better because we use high-level terms:
> interactive, never, and always.

Hmm yes but at the language level, ‘never’ is really #f.  Not big deal
though, so I’m fine either way.  (Actually, R6RS-style enums are probably
what we’d need here, but that’s OK.)

>> Modulo these details, it seems ready to get it.
>
> Can I push the attached version?
>
> What should I do next?  For instance, I can change 'guix refresh' to
> fetch signatures first and don't download tarballs that can't be
> authenticated (when signatures are missing and 'never' is used).

I don’t think it needs to be this fancy, IMO.

> Or I can fix it not to mix version numbers (not to update Guile 1.8.8
> to version 2.0.9).

This would be useful, because it’s a practical annoyance.

I’m not sure how to proceed.  The common pattern is packages that have
several series evolving in parallel, like GCC.  For those, we could add
something in the ‘properties’ field to say ‘dont-update’, and ‘guix
refresh’ could check for that item.

But what we really want to express is the fact that GCC 4.7.n should
only be upgraded to GCC 4.7.p, not GCC 4.8.

We could try to have a heuristic that guesses if we’re in such a
situation.  However that seems non-trivial, and possibly fragile.

Instead, the Grand Plan would be to have an additional field in
‘package’ records that provides info as to how to look for newer
versions.  Some of that info is currently in gnu-maintenance.scm (the
‘quirks’ variable).

I’m not sure about how to represent that info in a generic way.  There
are probably ideas to steal from Debian’s uscan and other distro tools.


Thoughts?

(Note: it’s OK, and perhaps even advisable, to start with the simplest
plan, and to leave the Grand Plan for later.)

>  (define* (download-tarball store project directory version
> -                           #:optional (archive-type "gz"))
> +                           #:key (archive-type "gz")
> +                                 (key-download 'interactive))
>    "Download PROJECT's tarball over FTP and check its OpenPGP signature.  On
> -success, return the tarball file name."
> +success, return the tarball file name.  KEY-DOWNLOAD specifies a download
> +policy for missing OpenPGP keys; allowed values: INTERACTIVE (default),
> +ALWAYS, and NEVER."

In the docstring, please write ‘interactive’, ‘always’, and ‘never’
lower-case and quoted, because these are not variable references.

(Same in other procedures.)

> +          (define (receive?)
> +            (let ((answer
> +                   (_ (begin (format #t "~a~a~%"
> +                                     "Would you like to download this key "
> +                                     "and add it to your keyring?")
> +                             (read-line)))))
> +              (string-match (locale-yes-regexp) answer)))

Should be:

  (let ((answer
          (begin
            (format #t (_ "Would you like..."))
            (read-line))))
    ...)

Please commit with these minor changes.

Thanks!

Ludo’.



reply via email to

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