Subject: Re: [bug#40485] Acknowledgement (gnu: Update libxfce4ui to 4.15.2.)

From: Danny Milosavljevic <[email-masked]>
Date: Thu, 9 Apr 2020 00:19:36 +0200

Hi Naga,

On Thu, 9 Apr 2020 01:13:34 +0530
Naga Malleswari <[email-masked]> wrote:

> https://paste.debian.net/1139190/

Please, for archival purposes, post source code in the mailing list.  Pastebin
content will eventually vanish--and we do want to have some kind of public
record.

I'm gonna paste it here:

CASE 1:

(define-public libxfce4ui-1
  (package
    (name "libxfce4ui")
    (version "4.14.1")

(define-public libxfce4ui/latest
  (package
    (inherit libxfce4ui-1)
    (version "4.15.2")

CASE 2:
(define-public libxfce4ui
  (package
    (name "libxfce4ui")
    (version "4.14.1")

(define-public libxfce4ui/latest
  (package
    (inherit libxfce4ui)
    (version "4.15.2")
    (source (origin
              (method url-fetch)
              (uri (string-append "https://archive.xfce.org/src/xfce/"
                                  name "/" (version-major+minor version) "/"
                                  name "-" version ".tar.bz2"))
              (sha256
               (base32
                "0069da27chxrgylbzcm9vhzpfnvkii2n2dz8g6jlwfcr82arkayb"))))))

> CASE1:
> 
>  ./pre-inst-env guix build libxfce4ui   is building 4.14.1

I would have expected 4.15.2--are you sure that you overwrote the field SOURCE ?

> ./pre-inst-env guix build libxfce4ui-1           error: libxfce4ui-1: unknown package

"libxfce4ui-1" is not a package's name but a variable's name.  That won't work[1].

> ./pre-inst-env guix build [email-masked]      error: libxfce4ui-4.15.2: unknown package

Why is there a dash in the error message?

Should work just fine with "@".

> CasE 2: 
>  ./pre-inst-env guix build libxfce4ui   is building 4.14.1

Should build 4.15.2.

> ./pre-inst-env guix build [email-masked]  resulted  error: libxfce4ui-4.15.2: unknown package

Again the dash?  Why?

it works for me:

diff --git a/gnu/packages/xfce.scm b/gnu/packages/xfce.scm
index 0628b03207..ee2bba5ca1 100644
--- a/gnu/packages/xfce.scm
+++ b/gnu/packages/xfce.scm
@@ -163,7 +163,9 @@ Xfce Desktop Environment.")
 storage system.")
     (license lgpl2.0+)))
 
-(define-public libxfce4ui
+;; case 1
+
+(define-public libxfce4ui-1
   (package
     (name "libxfce4ui")
     (version "4.14.1")
@@ -201,6 +203,20 @@ storage system.")
 to share commonly used Xfce widgets among the Xfce applications.")
     (license lgpl2.0+)))
 
+(define-public libxfce4ui
+  (package
+    (inherit libxfce4ui-1)
+    (name "libxfce4ui") ; not necessary but I like it for no reason
+    (version "4.15.2")
+    (source (origin ; necessary block!!
+              (method url-fetch)
+              (uri (string-append "https://archive.xfce.org/src/xfce/"
+                                  name "/" (version-major+minor version) "/"
+                                  name "-" version ".tar.bz2"))
+              (sha256
+               (base32
+                "0069da27chxrgylbzcm9vhzpfnvkii2n2dz8g6jlwfcr82arkayb"))))))
+
 (define-public exo
   (package
     (name "exo")

$ ./pre-inst-env guix build [email-masked]
/gnu/store/fk1ziblzyslg9z7gpm9j410jfgwbilsr-libxfce4ui-4.14.1

$ ./pre-inst-env guix build [email-masked]
/gnu/store/cy5wyx1zrq9ahp6zl0wjpv0nd0a6hpkb-libxfce4ui-4.15.2

The argument to "guix build" is always[1] the field called NAME (and optionally
also the field called VERSION, after an "@" separator) of the package record.
The variable's name (define-public xxx) doesn't matter at this point[1].

Because the sha256 sum would have to change (among other things), make sure to
specify the field SOURCE also in the other package--otherwise you'll get the
old source.

Another reason to specify SOURCE in the other package follows:

Guile, the programming language used for Guix packages, usually uses
lexical scope.
Even the facility we built in order to make records (like <PACKAGE>) also uses
lexical scope.

That means a reference will bind to the identifier that is closest in the source
code (before it).  Once the identifier is bound, that's it--it's not going to
change binding ever again.

That means if you do this (silly example to prove a point--but you can actually
run that for real!):

  (define-public a
    (package
      (name "a")
      (version name)
      ;; Please ignore the following line for understanding for now.
      (source #f) (build-system #f) (synopsis #f) (description #f) (license #f) (home-page #f)))

  (define-public b
    (package
      (inherit a)
      (name "b")))

  (write (package-name b))
  (newline)
  (write (package-version b))
  (newline)

package "b" would have: (name "b") but (version "a").
Version is "a".  That's not a typo.

However, with

  (define-public a
    (package
      (name "a")
      (version name) ; here, NAME is a reference, which will be bound to the NAME one line above
      ;; Please ignore the following line for understanding for now.
      (source #f) (build-system #f) (synopsis #f) (description #f) (license #f) (home-page #f)))

  (define-public b
    (package
      (inherit a)
      (name "b")
      (version name)))

  (write (package-name b))
  (newline)
  (write (package-version b))
  (newline)

package "b" would have: (name "b") and (version "b").

Similarly for all other references, most notably the references to NAME and VERSION that
usually occur in a SOURCE field.

[1] Except for "guix build -e ..." (don't use it).
    Usually, user-facing tools only care about the contents of the <PACKAGE> record.
    Guile variables are invisible to the end user of the "guix" tool.