[PATCH] Add cufflinks.

[PATCH] Add cufflinks.

[Ricardo Wurmus]

[-- Attachment #1: Type: text/plain, Size: 424 bytes --]

Hi Guix,

attached is a patch to add “cufflinks” to the bioinformatics module.
According to the authors, boost 1.56 broke the serialisation library in
some way, so “cufflinks” must be built against version 1.55.  They
expect this to be fixed in version 1.59 (current is 1.58).  This is why
this patch also adds a local variable “boost-1.55”, which is used by the
“cufflinks” package.

~~ Ricardo


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-gnu-Add-cufflinks.patch --]
[-- Type: text/x-patch, Size: 5460 bytes --]

From e8186326701df11ee4bdb22d4717cf4b8c27dd50 Mon Sep 17 00:00:00 2001
From: Ricardo Wurmus <ricardo.wurmus@mdc-berlin.de>
Date: Wed, 16 Sep 2015 17:42:41 +0200
Subject: [PATCH] gnu: Add cufflinks.

* gnu/packages/bioinformatics.scm (boost-1.55, cufflinks): New
  variables.
---
 gnu/packages/bioinformatics.scm | 99 +++++++++++++++++++++++++++++++++++++++++
 1 file changed, 99 insertions(+)

diff --git a/gnu/packages/bioinformatics.scm b/gnu/packages/bioinformatics.scm
index 1f34211..6a6b10f 100644
--- a/gnu/packages/bioinformatics.scm
+++ b/gnu/packages/bioinformatics.scm
@@ -837,6 +837,105 @@ files between different genome assemblies.  It supports most commonly used
 file formats including SAM/BAM, Wiggle/BigWig, BED, GFF/GTF, VCF.")
     (license license:gpl2+)))
 
+(define boost-1.55
+  (package (inherit boost)
+    (version "1.55.0")
+    (source (origin
+              (method url-fetch)
+              (uri (string-append
+                    "mirror://sourceforge/boost/boost_"
+                    (string-map (lambda (x) (if (eq? x #\.) #\_ x)) version)
+                    ".tar.bz2"))
+              (sha256
+               (base32
+                "0lkv5dzssbl5fmh2nkaszi8x9qbj80pr4acf9i26sj3rvlih1w7z"))))
+    (arguments
+     (substitute-keyword-arguments (package-arguments boost)
+       ((#:phases phases)
+        `(modify-phases ,phases
+           ;; The only difference from the "boost" package in that the "src"
+           ;; directory is called "v2" in this version.
+           (replace 'configure
+            (lambda* (#:key outputs #:allow-other-keys)
+              (let ((out (assoc-ref outputs "out")))
+                (substitute* '("libs/config/configure"
+                               "libs/spirit/classic/phoenix/test/runtest.sh"
+                               "tools/build/v2/doc/bjam.qbk"
+                               "tools/build/v2/engine/execunix.c"
+                               "tools/build/v2/engine/Jambase"
+                               "tools/build/v2/engine/jambase.c")
+                  (("/bin/sh") (which "sh")))
+
+                (setenv "SHELL" (which "sh"))
+                (setenv "CONFIG_SHELL" (which "sh"))
+
+                (zero? (system* "./bootstrap.sh"
+                                (string-append "--prefix=" out)
+                                "--with-toolset=gcc")))))))))))
+
+(define-public cufflinks
+  (package
+    (name "cufflinks")
+    (version "2.2.1")
+    (source (origin
+              (method url-fetch)
+              (uri (string-append "http://cole-trapnell-lab.github.io/"
+                                  "cufflinks/assets/downloads/cufflinks-"
+                                  version ".tar.gz"))
+              (sha256
+               (base32
+                "1bnm10p8m7zq4qiipjhjqb24csiqdm1pwc8c795z253r2xk6ncg8"))))
+    (build-system gnu-build-system)
+    (arguments
+     `(#:phases
+       (modify-phases %standard-phases
+         (add-after 'unpack 'fix-search-for-bam
+          (lambda _
+            (substitute* '("ax_bam.m4"
+                           "configure"
+                           "src/hits.h")
+              (("<bam/sam\\.h>") "<samtools/sam.h>")
+              (("<bam/bam\\.h>") "<samtools/bam.h>")
+              (("<bam/version\\.hpp>") "<samtools/version.h>"))
+            #t))
+         (add-after 'unpack 'set-CPATH-and-LDFLAGS
+          (lambda* (#:key inputs #:allow-other-keys)
+            ;; The includes for "eigen" are located in a subdirectory.
+            (setenv "CPATH" (string-append (assoc-ref inputs "eigen")
+                                           "/include/eigen3/" ":"
+                                           (or (getenv "CPATH") "")))
+            ;; Cufflinks must be linked with various boost libraries.
+            (setenv "LDFLAGS" (string-join '("-lboost_system"
+                                             "-lboost_serialization"
+                                             "-lboost_thread")
+                                           " "))
+            #t)))
+       #:configure-flags
+       (list (string-append "--with-bam="
+                            (assoc-ref %build-inputs "samtools")))))
+    (inputs
+     `(("eigen" ,eigen)
+       ("samtools" ,samtools-0.1)
+       ("htslib" ,htslib)
+       ;; Due to a serious issue with Boost Serialization library introduced
+       ;; in version 1.56, Cufflinks currently can only be built with Boost
+       ;; version 1.55 or lower. The issue is expected to be fixed in the
+       ;; upcoming Boost v1.59.
+       ("boost-1.55" ,boost-1.55)
+       ("python" ,python-2)
+       ("zlib" ,zlib)))
+    (home-page "http://cole-trapnell-lab.github.io/cufflinks/")
+    (synopsis "Transcriptome assembly and RNA-Seq expression analysis")
+    (description
+     "Cufflinks assembles transcripts, estimates their abundances, and tests
+for differential expression and regulation in RNA-Seq samples.  It accepts
+aligned RNA-Seq reads and assembles the alignments into a parsimonious set of
+transcripts.  Cufflinks then estimates the relative abundances of these
+transcripts based on how many reads support each one, taking into account
+biases in library preparation protocols.")
+    (license (license:x11-style "http://www.boost.org/LICENSE_1_0.txt"
+                                "Some components have other similar licences."))))
+
 (define-public cutadapt
   (package
     (name "cutadapt")
-- 
2.1.0

Re: [PATCH] Add cufflinks.

[Ludovic Courtès]

Ricardo Wurmus <ricardo.wurmus@mdc-berlin.de> skribis:

> From e8186326701df11ee4bdb22d4717cf4b8c27dd50 Mon Sep 17 00:00:00 2001
> From: Ricardo Wurmus <ricardo.wurmus@mdc-berlin.de>
> Date: Wed, 16 Sep 2015 17:42:41 +0200
> Subject: [PATCH] gnu: Add cufflinks.
>
> * gnu/packages/bioinformatics.scm (boost-1.55, cufflinks): New
>   variables.

[...]

> +(define boost-1.55
> +  (package (inherit boost)

I would keep it next to ‘boost’.


[...]

> +          (lambda* (#:key inputs #:allow-other-keys)
> +            ;; The includes for "eigen" are located in a subdirectory.
> +            (setenv "CPATH" (string-append (assoc-ref inputs "eigen")
> +                                           "/include/eigen3/" ":"
> +                                           (or (getenv "CPATH") "")))

It should be using ‘pkg-config eigen3 --cflags’, but pkg-config is
missing.

Could you check if adding pkg-config makes this hack unnecessary?

Otherwise LGTM.

Thanks,
Ludo’.

Re: [PATCH] Add cufflinks.

[Andreas Enge]

On Wed, Sep 16, 2015 at 07:10:08PM +0200, Ludovic Courtès wrote:
> > +(define boost-1.55
> > +  (package (inherit boost)
> I would keep it next to ‘boost’.

If it is just a temporary work-around that will disappear at the next release,
it might make sense to keep it as a private variable next to its use.

Actually, boost-1.59.0 has been released on August 13. So the easiest
approach might be to wait for the core-updates merge, then update boost,
then add the new package.

Andreas

Re: [PATCH] Add cufflinks.

[Ludovic Courtès]

Andreas Enge <andreas@enge.fr> skribis:

> On Wed, Sep 16, 2015 at 07:10:08PM +0200, Ludovic Courtès wrote:
>> > +(define boost-1.55
>> > +  (package (inherit boost)
>> I would keep it next to ‘boost’.
>
> If it is just a temporary work-around that will disappear at the next release,
> it might make sense to keep it as a private variable next to its use.

Yes, but my concern is that someone else might end up duplicating
boost-1.55 elsewhere.

Also, it’s best to avoid top-level references to variables of another
module.

Ludo’.

Re: [PATCH] Add cufflinks.

[Ricardo Wurmus]

Andreas Enge <andreas@enge.fr> writes:

> On Wed, Sep 16, 2015 at 07:10:08PM +0200, Ludovic Courtès wrote:
>> > +(define boost-1.55
>> > +  (package (inherit boost)
>> I would keep it next to ‘boost’.
>
> If it is just a temporary work-around that will disappear at the next release,
> it might make sense to keep it as a private variable next to its use.

Yes, that’s what I thought.  I didn’t want to expose a public
“boost-1.55” package only because a package in bioinformatics.scm needs
that particular version.

> Actually, boost-1.59.0 has been released on August 13. So the easiest
> approach might be to wait for the core-updates merge, then update boost,
> then add the new package.

Oh, I didn’t know.  That would be okay as well, I guess.

~~ Ricardo

[PATCH 0/1] Provide icons for transmission-gtk

[Leo Famulari]

Currently, transmission-gtk can't find the icons for its GUI. It
complains on the console about not being able to find adwaita and
hicolor, and there are unlabelled buttons.

I noticed in the git log that some commits of this type (Add
dependencies) capitalize the name of the dependency. Should I amend this
commit?

Leo Famulari (1):
  gnu: transmission-gtk: Add icon dependencies.

 gnu/packages/bittorrent.scm | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

-- 
2.7.0.rc3

[PATCH 1/1] gnu: transmission-gtk: Add icon dependencies.

[Leo Famulari]

* gnu/packages/bittorrent.scm (transmission)[inputs]: Add
adwaita-icon-theme and hicolor-icon-theme.
---
 gnu/packages/bittorrent.scm | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/gnu/packages/bittorrent.scm b/gnu/packages/bittorrent.scm
index 967580d..74770dc 100644
--- a/gnu/packages/bittorrent.scm
+++ b/gnu/packages/bittorrent.scm
@@ -1,6 +1,7 @@
 ;;; GNU Guix --- Functional package management for GNU
 ;;; Copyright © 2014 Taylan Ulrich Bayirli/Kammer <taylanbayirli@gmail.com>
 ;;; Copyright © 2014, 2015 Ludovic Courtès <ludo@gnu.org>
+;;; Copyright © 2016 Leo Famulari <leo@famulari.name>
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -30,6 +31,7 @@
   #:use-module (gnu packages linux)
   #:use-module (gnu packages compression)
   #:use-module (gnu packages glib)
+  #:use-module (gnu packages gnome)
   #:use-module (gnu packages gtk)
   #:use-module (gnu packages check)
   #:use-module (gnu packages ncurses)
@@ -73,7 +75,9 @@
        ("openssl" ,openssl)
        ("file" ,file)
        ("zlib" ,zlib)
-       ("gtk+" ,gtk+)))
+       ("gtk+" ,gtk+)
+       ("adwaita-icon-theme" ,adwaita-icon-theme)
+       ("hicolor-icon-theme" ,hicolor-icon-theme)))
     (native-inputs
      `(("intltool" ,intltool)
        ("pkg-config" ,pkg-config)))
-- 
2.7.0.rc3

Re: [PATCH 1/1] gnu: transmission-gtk: Add icon dependencies.

[Ludovic Courtès]

Leo Famulari <leo@famulari.name> skribis:

> * gnu/packages/bittorrent.scm (transmission)[inputs]: Add
> adwaita-icon-theme and hicolor-icon-theme.

I don’t think we should take that route, because we would end up doing
that for each and every GTK+ package.

However, we could:

  1. On GuixSD, arrange so that these two things are automatically
     installed as part of %desktop-services.

  2. Augment “Application Setup” to suggest installing icon theme when
     using Guix on foreign distros.

WDYT?

Ludo’.

Re: [PATCH 1/1] gnu: transmission-gtk: Add icon dependencies.

[Leo Famulari]

On Fri, Jan 22, 2016 at 06:15:11PM +0100, Ludovic Courtès wrote:
> Leo Famulari <leo@famulari.name> skribis:
> 
> > * gnu/packages/bittorrent.scm (transmission)[inputs]: Add
> > adwaita-icon-theme and hicolor-icon-theme.
> 
> I don’t think we should take that route, because we would end up doing
> that for each and every GTK+ package.

If it's true that all GTK+ packages depend on these icons, would it make
sense to alter the glib-or-gtk-build-system to provide them?

> 
> However, we could:
> 
>   1. On GuixSD, arrange so that these two things are automatically
>      installed as part of %desktop-services.
> 
>   2. Augment “Application Setup” to suggest installing icon theme when
>      using Guix on foreign distros.

I have adwaita-icon-theme and hicolor-icon-theme in my profile, but when
running transmission-gtk, it complains on stderr about problems with
both icon themes and has no icons at all:

--start-example- 
(transmission-gtk:21008): Gtk-WARNING **: Could not find the icon 'document-open'. The 'hicolor' theme
was not found either, perhaps you need to install it.

(transmission-gtk:20986): Gtk-WARNING **: Error loading theme icon 'network-idle' for stock: Icon 'network-idle' not present in theme Adwaita
--end-example--

Is this working for anyone else?

I haven't found a way to provide the correct paths at build time, but
I'm not very familiar with this build system.

> 
> WDYT?
> 
> Ludo’.

Re: [PATCH] Add cufflinks.

[Ricardo Wurmus]

Ludovic Courtès <ludo@gnu.org> writes:

> Ricardo Wurmus <ricardo.wurmus@mdc-berlin.de> skribis:
>
>> From e8186326701df11ee4bdb22d4717cf4b8c27dd50 Mon Sep 17 00:00:00 2001
>> From: Ricardo Wurmus <ricardo.wurmus@mdc-berlin.de>
>> Date: Wed, 16 Sep 2015 17:42:41 +0200
>> Subject: [PATCH] gnu: Add cufflinks.
>>
>> * gnu/packages/bioinformatics.scm (boost-1.55, cufflinks): New
>>   variables.
>
> [...]
>
>> +(define boost-1.55
>> +  (package (inherit boost)
>
> I would keep it next to ‘boost’.

Since the update to boost 1.60 this is no longer needed.

>> +          (lambda* (#:key inputs #:allow-other-keys)
>> +            ;; The includes for "eigen" are located in a subdirectory.
>> +            (setenv "CPATH" (string-append (assoc-ref inputs "eigen")
>> +                                           "/include/eigen3/" ":"
>> +                                           (or (getenv "CPATH") "")))
>
> It should be using ‘pkg-config eigen3 --cflags’, but pkg-config is
> missing.
>
> Could you check if adding pkg-config makes this hack unnecessary?
>
> Otherwise LGTM.

Cufflinks does not use pkg-config.  I have modified this to use
EIGEN_CPPFLAGS instead of the much broader CPATH:

+    (arguments
+     `(#:make-flags
+       (list
+        ;; The includes for "eigen" are located in a subdirectory.
+        (string-append "EIGEN_CPPFLAGS="
+                       "-I" (assoc-ref %build-inputs "eigen")
+                       "/include/eigen3/")

I have also cleaned up the package to use “modify-phases”, clarified the
description (“transcript” -> “RNA transcript”), and replaced the license
with “license:boost1.0”.

~~ Ricardo

Re: [PATCH 1/1] gnu: transmission-gtk: Add icon dependencies.

[Ludovic Courtès]

Leo Famulari <leo@famulari.name> skribis:

> I have adwaita-icon-theme and hicolor-icon-theme in my profile, but when
> running transmission-gtk, it complains on stderr about problems with
> both icon themes and has no icons at all:
>
> --start-example- 
> (transmission-gtk:21008): Gtk-WARNING **: Could not find the icon 'document-open'. The 'hicolor' theme
> was not found either, perhaps you need to install it.
>
> (transmission-gtk:20986): Gtk-WARNING **: Error loading theme icon 'network-idle' for stock: Icon 'network-idle' not present in theme Adwaita
> --end-example--
>
> Is this working for anyone else?

It works wonderfully well for me on GuixSD!

Thanks, bye.

;-)

Seriously though, I think the trick is to have the XDG variables
correctly set, which is done automatically on GuixSD:

--8<---------------cut here---------------start------------->8---
$ env | grep XDG
XDG_CONFIG_DIRS=/home/ludo/.guix-profile/etc/xdg:/run/current-system/profile/etc/xdg
XDG_DATA_DIRS=/gnu/store/jhkid4l3w4wkq01gsqw3sfzzivy0y8vw-glib-2.46.1/share:/gnu/store/jzzsyrvyacsjkpj82bjq0qgy28j8yk35-gtk+-3.18.2/share:/gnu/store/sw8k4554wav93l5ffh0hk6mxq4krhfw2-emacs-24.5/share:/gnu/store/jhkid4l3w4wkq01gsqw3sfzzivy0y8vw-glib-2.46.1/share:/gnu/store/jzzsyrvyacsjkpj82bjq0qgy28j8yk35-gtk+-3.18.2/share:/gnu/store/sw8k4554wav93l5ffh0hk6mxq4krhfw2-emacs-24.5/share:/run/current-system/profile/share:/home/ludo/.guix-profile/share:/run/current-system/profile/share
--8<---------------cut here---------------end--------------->8---

Does it work for you?

Thanks,
Ludo’.

Add "guix update" command

[Fabian Harfert]

Hello,

on IRC I already mentioned that, but there wasn't much resonance: I
think for the purposes of non-developers the behavior of the "guix
pull" command is too complicated.

Normal users don't need a development version of the package manager,
when they just want to get the newest package definitions to update
their installed software. So it would be much easier and faster if
there was a separate repository just containing the most recent package
definitions.

I propose to add a new command line option - e.g. "guix update" -
fetching these latest package definitions and not doing anything else.
They could be contained by a package whose definition is downloaded,
for example "guix-packages".

To avoid compatibility issues when there's a new release of Guix itself
this package must be versioned equal to the Guix version numbers. I'm
thinking of the following:

  The user is running Guix 1.2.1 and has installed the package
  guix-packages-1.2.1-4 containing the package definitions. Now he runs
  "guix update" and fetches guix-packages-1.2.1-5 with the new package
  definitions including the new Guix release 1.2.2. He now updates Guix
  to this version which has the new guix-packages-1.2.2-0 as an input.
  When he runs "guix update" again, guix-packages-1.2.2-1 is installed,
  which contains package definitions that make use of some new features.

This would just be for the time between the Guix releases. I think we
don't need support for older versions of Guix except from keeping the
last guix-packages package, but we could also do some security
or minor updates to the older package definitions which would provide
users the possibility to use GuixSD as a stable distribution like
Debian.

Another advantage of the separation between Guix itself and the package
definitions is that it's easy to provide an own or foreign
guix-packages package which would promote the decentralization of Guix.

Initially I thought of doing the same for service definitions except
from the basic ones. But I think that version compatibility problems
would occur more often because service definitions are at a lower level
than the package definitions. In addition the notorious normal users
won't change so much of their service definitions.

Fabian

Add "guix update" command

[Fabian Harfert]

Hello,

on IRC I already mentioned that, but there wasn't much resonance: I
think for the purposes of non-developers the behavior of the "guix
pull" command is too complicated.

Normal users don't need a development version of the package manager,
when they just want to get the newest package definitions to update
their installed software. So it would be much easier and faster if
there was a separate repository just containing the most recent package
definitions.

I propose to add a new command line option - e.g. "guix update" -
fetching these latest package definitions and not doing anything else.
They could be contained by a package whose definition is downloaded,
for example "guix-packages".

To avoid compatibility issues when there's a new release of Guix itself
this package must be versioned equal to the Guix version numbers. I'm
thinking of the following:

  The user is running Guix 1.2.1 and has installed the package
  guix-packages-1.2.1-4 containing the package definitions. Now he runs
  "guix update" and fetches guix-packages-1.2.1-5 with the new package
  definitions including the new Guix release 1.2.2. He now updates Guix
  to this version which has the new guix-packages-1.2.2-0 as an input.
  When he runs "guix update" again, guix-packages-1.2.2-1 is installed,
  which contains package definitions that make use of some new features.

This would just be for the time between the Guix releases. I think we
don't need support for older versions of Guix except from keeping the
last guix-packages package, but we could also do some security
or minor updates to the older package definitions which would provide
users the possibility to use GuixSD as a stable distribution like
Debian.

Another advantage of the separation between Guix itself and the package
definitions is that it's easy to provide an own or foreign
guix-packages package which would promote the decentralization of Guix.

Initially I thought of doing the same for service definitions except
from the basic ones. But I think that version compatibility problems
would occur more often because service definitions are at a lower level
than the package definitions. In addition the notorious normal users
won't change so much of their service definitions.

Fabian


I don't know why this E-Mail is shown as a reply to the transmission
patch, so I send it again, sorry.

Re: Add "guix update" command

[Friedrich Herbst]

Excuse me, that doesn't belong to the transmission thread.

Re: Add "guix update" command

[Christopher Allan Webber]

Fabian Harfert writes:

> Hello,
>
> on IRC I already mentioned that, but there wasn't much resonance: I
> think for the purposes of non-developers the behavior of the "guix
> pull" command is too complicated.
>
> Normal users don't need a development version of the package manager,
> when they just want to get the newest package definitions to update
> their installed software. So it would be much easier and faster if
> there was a separate repository just containing the most recent package
> definitions.
>
> I propose to add a new command line option - e.g. "guix update" -
> fetching these latest package definitions and not doing anything else.
> They could be contained by a package whose definition is downloaded,
> for example "guix-packages".
>
> To avoid compatibility issues when there's a new release of Guix itself
> this package must be versioned equal to the Guix version numbers. I'm
> thinking of the following:
>
>   The user is running Guix 1.2.1 and has installed the package
>   guix-packages-1.2.1-4 containing the package definitions. Now he runs
>   "guix update" and fetches guix-packages-1.2.1-5 with the new package
>   definitions including the new Guix release 1.2.2. He now updates Guix
>   to this version which has the new guix-packages-1.2.2-0 as an input.
>   When he runs "guix update" again, guix-packages-1.2.2-1 is installed,
>   which contains package definitions that make use of some new features.
>
> This would just be for the time between the Guix releases. I think we
> don't need support for older versions of Guix except from keeping the
> last guix-packages package, but we could also do some security
> or minor updates to the older package definitions which would provide
> users the possibility to use GuixSD as a stable distribution like
> Debian.
>
> Another advantage of the separation between Guix itself and the package
> definitions is that it's easy to provide an own or foreign
> guix-packages package which would promote the decentralization of Guix.

I'm not really for this.  It would require a lot of careful planning.
Additionally, right now the packages depend on Guix code generally, so
as Guix evolves its internal APIs, packages shipped with it can depend
on that.  That seems valuable for the "core" set of packages.

I'm afraid we'd lose this if we'd take the above suggested route.

Re: Add "guix update" command

[Thompson, David]

Hi Fabian,

This isn't the first time I've seen such a proposal, and while I
appreciate the viewpoint, I don't think this would be a good decision
for Guix and I'm fairly sure that the other developers agree.  See
below for further explanation.

On Sat, Jan 23, 2016 at 1:11 PM, Fabian Harfert <fhmgufs@web.de> wrote:
> Hello,
>
> on IRC I already mentioned that, but there wasn't much resonance: I
> think for the purposes of non-developers the behavior of the "guix
> pull" command is too complicated.
>
> Normal users don't need a development version of the package manager,
> when they just want to get the newest package definitions to update
> their installed software. So it would be much easier and faster if
> there was a separate repository just containing the most recent package
> definitions.

In Guix, we purposely do not distinguish between a user and a
developer because we believe there is no distinction.  We think the
perceived line between user and developer should be blurred.  Everyone
should be enabled to hack on Guix, and introducing things that
differentiate developers from "regular users" is counter-productive to
our goal.

> I propose to add a new command line option - e.g. "guix update" -
> fetching these latest package definitions and not doing anything else.
> They could be contained by a package whose definition is downloaded,
> for example "guix-packages".
>
> To avoid compatibility issues when there's a new release of Guix itself
> this package must be versioned equal to the Guix version numbers. I'm
> thinking of the following:
>
>   The user is running Guix 1.2.1 and has installed the package
>   guix-packages-1.2.1-4 containing the package definitions. Now he runs
>   "guix update" and fetches guix-packages-1.2.1-5 with the new package
>   definitions including the new Guix release 1.2.2. He now updates Guix
>   to this version which has the new guix-packages-1.2.2-0 as an input.
>   When he runs "guix update" again, guix-packages-1.2.2-1 is installed,
>   which contains package definitions that make use of some new features.

This additional complexity is one of the reasons why packages are not
maintained separately from everything else.  We know exactly what the
outcome of such a scheme would look like because this is what Nix
does.  Nix, the package manager, exists separately from nixpkgs, which
contains all the package recipes.  This was deliberately avoided when
the Guix project was started to avoid compatibility issues.

By maintaining the packages separately from Guix itself, we must turn
internal APIs into external APIs and become very concerned with
backwards compatibility.  We follow an approach similar to Linux.  In
Linux, kernel modules are maintained in the same source tree as the
kernel itself.  The reason for this is it allows the kernel developers
to introduce changes to internal APIs and update *all* of the modules
affected, together.  This greatly simplifies maintenance and the
ability to improve the software without introducing compatibility
issues.  Being able to break internal APIs when needed is something we
simply could not afford to give up, at least not at this stage in
Guix's development.

Another reason is simply practical.  Having patch sets that span
multiple repositories is cumbersome.  I know this all too well because
I work at a company that has a lot of repository proliferation.  It's
not uncommon for a new feature to span 3 Git repos, and keep
everything in order is a pain.

> This would just be for the time between the Guix releases. I think we
> don't need support for older versions of Guix except from keeping the
> last guix-packages package, but we could also do some security
> or minor updates to the older package definitions which would provide
> users the possibility to use GuixSD as a stable distribution like
> Debian.

A stable version of Guix would be nothing more (or less) than a branch
in Git that received only critical security updates.

> Another advantage of the separation between Guix itself and the package
> definitions is that it's easy to provide an own or foreign
> guix-packages package which would promote the decentralization of Guix.

This point is moot because it's already easy to include other package
recipes via the GUIX_PACKAGE_PATH environment variable.  See:
https://gnu.org/software/guix/manual/html_node/Package-Modules.html#Package-Modules

> Initially I thought of doing the same for service definitions except
> from the basic ones. But I think that version compatibility problems
> would occur more often because service definitions are at a lower level
> than the package definitions. In addition the notorious normal users
> won't change so much of their service definitions.

Services are at a higher level, actually.  Services often use package
objects in the g-expressions that define the service configuration.
This is a good example of why Guix is a unified whole, and separating
packages from the rest would only leads to strange incompatibility
problems.

Hope this helps!

- Dave

Re: Add "guix update" command

[Ludovic Courtès]

Hi!

I very much agree with what David wrote.

Note that NixOS has been merged into Nixpkgs several months ago
precisely for the reasons David gave.

That Nix remains separate from Nixpkgs/NixOS can be problematic because
as new features of Nix language get used in Nixpkgs,
backward-compatibility is broken (and adding features to the language is
not uncommon since Nix is an external DSL that becomes less and less DS,
as is often the case with DSLs ;-)).

Ludo’.

Re: [PATCH 1/1] gnu: transmission-gtk: Add icon dependencies.

[Leo Famulari]

On Sat, Jan 23, 2016 at 05:36:28PM +0100, Ludovic Courtès wrote:
> Leo Famulari <leo@famulari.name> skribis:
> 
> > I have adwaita-icon-theme and hicolor-icon-theme in my profile, but when
> > running transmission-gtk, it complains on stderr about problems with
> > both icon themes and has no icons at all:
> >
> > --start-example- 
> > (transmission-gtk:21008): Gtk-WARNING **: Could not find the icon 'document-open'. The 'hicolor' theme
> > was not found either, perhaps you need to install it.
> >
> > (transmission-gtk:20986): Gtk-WARNING **: Error loading theme icon 'network-idle' for stock: Icon 'network-idle' not present in theme Adwaita
> > --end-example--
> >
> > Is this working for anyone else?
> 
> It works wonderfully well for me on GuixSD!
> 
> Thanks, bye.
> 
> ;-)
> 
> Seriously though, I think the trick is to have the XDG variables
> correctly set, which is done automatically on GuixSD:
> 
> --8<---------------cut here---------------start------------->8---
> $ env | grep XDG
> XDG_CONFIG_DIRS=/home/ludo/.guix-profile/etc/xdg:/run/current-system/profile/etc/xdg
> XDG_DATA_DIRS=/gnu/store/jhkid4l3w4wkq01gsqw3sfzzivy0y8vw-glib-2.46.1/share:/gnu/store/jzzsyrvyacsjkpj82bjq0qgy28j8yk35-gtk+-3.18.2/share:/gnu/store/sw8k4554wav93l5ffh0hk6mxq4krhfw2-emacs-24.5/share:/gnu/store/jhkid4l3w4wkq01gsqw3sfzzivy0y8vw-glib-2.46.1/share:/gnu/store/jzzsyrvyacsjkpj82bjq0qgy28j8yk35-gtk+-3.18.2/share:/gnu/store/sw8k4554wav93l5ffh0hk6mxq4krhfw2-emacs-24.5/share:/run/current-system/profile/share:/home/ludo/.guix-profile/share:/run/current-system/profile/share
> --8<---------------cut here---------------end--------------->8---

It worked!

Should these be added as search-paths in the transmission package
definition?

What is the desired effect of setting XDG_CONFIG_DIRS that way? Aren't
those directories still read-only?

There is also the warning message:
GLib-GIO-Message: Using the 'memory' GSettings backend.  Your settings will not be saved or shared with other applications.

... but that is simply not true. The settings are saved as expected
under ~/.config/transmission


> 
> Does it work for you?
> 
> Thanks,
> Ludo’.

Re: [PATCH 1/1] gnu: transmission-gtk: Add icon dependencies.

[Ludovic Courtès]

Leo Famulari <leo@famulari.name> skribis:

[...]

>> Seriously though, I think the trick is to have the XDG variables
>> correctly set, which is done automatically on GuixSD:
>> 
>> --8<---------------cut here---------------start------------->8---
>> $ env | grep XDG
>> XDG_CONFIG_DIRS=/home/ludo/.guix-profile/etc/xdg:/run/current-system/profile/etc/xdg
>> XDG_DATA_DIRS=/gnu/store/jhkid4l3w4wkq01gsqw3sfzzivy0y8vw-glib-2.46.1/share:/gnu/store/jzzsyrvyacsjkpj82bjq0qgy28j8yk35-gtk+-3.18.2/share:/gnu/store/sw8k4554wav93l5ffh0hk6mxq4krhfw2-emacs-24.5/share:/gnu/store/jhkid4l3w4wkq01gsqw3sfzzivy0y8vw-glib-2.46.1/share:/gnu/store/jzzsyrvyacsjkpj82bjq0qgy28j8yk35-gtk+-3.18.2/share:/gnu/store/sw8k4554wav93l5ffh0hk6mxq4krhfw2-emacs-24.5/share:/run/current-system/profile/share:/home/ludo/.guix-profile/share:/run/current-system/profile/share
>> --8<---------------cut here---------------end--------------->8---
>
> It worked!
>
> Should these be added as search-paths in the transmission package
> definition?

No, these are in ‘glib’, but see <http://bugs.gnu.org/22138>.

> What is the desired effect of setting XDG_CONFIG_DIRS that way? Aren't
> those directories still read-only?

The purpose is to make “these things” work; it’s briefly mentioned in
the manual (info "(guix) Build Systems").

> There is also the warning message:
> GLib-GIO-Message: Using the 'memory' GSettings backend.  Your settings will not be saved or shared with other applications.
>
> ... but that is simply not true. The settings are saved as expected
> under ~/.config/transmission

I have:

--8<---------------cut here---------------start------------->8---
$ /gnu/store/lxi4bp22sqmz0g8wf0i171pxgv871wcc-transmission-2.84-gui/bin/transmission-gtk 

** (transmission-gtk:28007): WARNING **: Error retrieving accessibility bus address: org.freedesktop.DBus.Error.ServiceUnknown: The name org.a11y.Bus was not provided by any .service files

(transmission-gtk:28007): GLib-GIO-WARNING **: Failed to execute child process "update-desktop-database" (No such file or directory)
--8<---------------cut here---------------end--------------->8---

(I think in general you could check whether there are discrepancies
between your system and GuixSD using ‘guix system vm’, with
‘transmission:gui’ installed globally.)

Ludo’.