Re: GNOME updater

[Ludovic Courtès]

Efraim Flashner <address@hidden> skribis:

> On Tue, 08 Dec 2015 16:11:55 +0100
> address@hidden (Ludovic Courtès) wrote:
>
>> Efraim Flashner <address@hidden> skribis:
>> 
>> > A for gnome-3, the 3.19 series AFAIK is the beta/development releases for
>> > 3.20, so would we want to update to those numbers?  
>> 
>> Good point, we probably don’t want those.
>> 
>> Fixed in c499125, which leads to a shorter list:
>> 
>>[snip]
>  
> it might need a bit more work. For example, vte is at 0.40.0 and current
> upstream is 0.43.0, but presumably there is a 0.42.x release in there
> somewhere. Or at least for gnome-mines and -terminal, I'm sure there's a 3.18
> release between our 3.16.x and upstream 3.19.x.
>
> I tried a bit at the logic but wasn't able to quickly figure something out.
> As a test at-spi2-atk in gtk.scm can be upgraded to 2.18.3.

With the patch below, here’s what I get:

--8<---------------cut here---------------start------------->8---
$ ./pre-inst-env guix refresh at-spi2-core gtk+ gnome-mines vte gnome-terminal 
gnu/packages/gnome.scm:2168:13: gnome-terminal would be upgraded from 3.16.0 to 
3.18.2
gnu/packages/gnome.scm:1687:13: vte would be upgraded from 0.40.0 to 0.42.1
gnu/packages/gnome.scm:2122:13: gnome-mines would be upgraded from 3.16.0 to 
3.18.2
gnu/packages/gtk.scm:573:12: gtk+ would be upgraded from 3.18.2 to 3.18.6
gnu/packages/gtk.scm:437:12: at-spi2-core would be upgraded from 2.18.1 to 
2.18.3
--8<---------------cut here---------------end--------------->8---

That looks good now, no?

diff --git a/guix/gnu-maintenance.scm b/guix/gnu-maintenance.scm
index 910270f..fb54036 100644
--- a/guix/gnu-maintenance.scm
+++ b/guix/gnu-maintenance.scm
@@ -328,8 +328,8 @@ pairs.  Example: (\"mit-scheme-9.0.1\" . 
\"/gnu/mit-scheme/stable.pkg/9.0.1\").
 under DIRECTORY, or #f.  Use FTP-OPEN and FTP-CLOSE to open (resp. close) FTP
 connections; this can be useful to reuse connections.
 
-KEEP-FILE? is a predicate to decide whether to consider a given file (source
-tarball) as a valid candidate based on its name.
+KEEP-FILE? is a predicate to decide whether to enter a directory and to
+consider a given file (source tarball) as a valid candidate based on its name.
 
 FILE->SIGNATURE must be a procedure; it is passed a source file URL and must
 return the corresponding signature URL, or #f it signatures are unavailable."
@@ -376,7 +376,7 @@ return the corresponding signature URL, or #f it signatures 
are unavailable."
                                   (("w32" 'directory . _)
                                    #f)
                                   (((? contains-digit? dir) 'directory . _)
-                                   dir)
+                                   (and (keep-file? dir) dir))
                                   (_ #f))
                                 entries))
 
@@ -480,14 +480,13 @@ elpa.gnu.org, and all the GNOME packages."
     (match (string-tokenize (version-major+minor version)
                             %not-dot)
       (((= string->number major) (= string->number minor))
-       (even? minor))
+       (and minor (even? minor)))
       (_
        #t)))                                      ;cross fingers
 
-  (define (even-numbered-tarball? file)
-    (let-values (((name version) (gnu-package-name->name+version file)))
-      (and version
-           (even-minor-version? version))))
+  (define (even-numbered? file)
+    (let-values (((name version) (package-name->name+version file)))
+      (even-minor-version? (or version name))))
 
   (false-if-ftp-error
    (latest-ftp-release package
@@ -501,7 +500,7 @@ elpa.gnu.org, and all the GNOME packages."
                        ;; <https://www.gnome.org/gnome-3/source/> explains
                        ;; that odd minor version numbers represent development
                        ;; releases, which we are usually not interested in.
-                       #:keep-file? even-numbered-tarball?
+                       #:keep-file? even-numbered?
 
                        ;; ftp.gnome.org provides no signatures, only
                        ;; checksums.

>> > Also, if we don't want to use those releases, we should check if the
>> > other packages also use the odd (version minor-version) numbers as a
>> > symbol for beta/rc releases.  
>> 
>> This is checked for GNU packages already, and I assume there’s no notion
>> of “unstable” releases on repos such as PyPI and CRAN?
>
> Could this also be a problem for GNU packages? If we didn't update to the
> latest release before they put out a new development version?

There could be exception, but in general, GNU packages put development
releases on alpha.gnu.org, so we shouldn’t have this problem.

Thanks!

Ludo’.