Problems with downloading from https

Problems with downloading from https

[Alex Kost]

Hello, I noticed <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=18831>
and decided to ask about a similar problem I have.

Whenever I try to download anything from https, I get an error, for
example:

--8<---------------cut here---------------start------------->8---
$ guix download https://savannah.gnu.org/projects/guix/
starting download of `/tmp/guix-file.Z7tZhy' from `https://savannah.gnu.org/projects/guix/'...
;;; Failed to autoload make-session in (gnutls):
;;; ERROR: missing interface for module (gnutls)
ERROR: In procedure module-lookup: Unbound variable: make-session
failed to download "/tmp/guix-file.Z7tZhy" from "https://savannah.gnu.org/projects/guix/"
guix download: error: https://savannah.gnu.org/projects/guix/: download failed
--8<---------------cut here---------------end--------------->8---

I have a feeling that I'm missing something obvious but I can't figure
it out.  Any help appreciated.

-- 
Thanks,
Alex

Re: Problems with downloading from https

[Ian Denhardt]

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

Quoting Alex Kost (2014-10-25 13:30:26)
> Hello, I noticed <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=18831>
> and decided to ask about a similar problem I have.
> 
> Whenever I try to download anything from https, I get an error, for
> example:
> 
> --8<---------------cut here---------------start------------->8---
> $ guix download https://savannah.gnu.org/projects/guix/
> starting download of `/tmp/guix-file.Z7tZhy' from `https://savannah.gnu.org/projects/guix/'...
> ;;; Failed to autoload make-session in (gnutls):
> ;;; ERROR: missing interface for module (gnutls)
> ERROR: In procedure module-lookup: Unbound variable: make-session
> failed to download "/tmp/guix-file.Z7tZhy" from "https://savannah.gnu.org/projects/guix/"
> guix download: error: https://savannah.gnu.org/projects/guix/: download failed
> --8<---------------cut here---------------end--------------->8---
> 
> I have a feeling that I'm missing something obvious but I can't figure
> it out.  Any help appreciated.

Huh, I assumed this was just me having set up something wrong. Either
this is an actual bug, or we've hit the same pitfall with configuration.

Do others have this working? What's your setup like? I'm running in a
git checkout on an up-to-date Archlinux system, set up according to the
instructions in the README.

-Ian

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAABAgAGBQJUTAHqAAoJEPZUuMfUyjy4aSQP/ik4ywiwj5IIZv5gRo1do8iu
BcAwVMpnoN4JKSEOAGIbiphwUyMcxNQNMPJGzOa4waisJ7iB9soSO7sMEZe/Dq3Y
7i6kWl1T1S6jqHlHpKnmSzGE9kQYGB/5DcC9dX6+kG9D8Z4/vyvZ1eWj6FpkgH14
GtgtsYMbrY6wR4+2ix99JCKQwTdUdjuP3olntOiyorrRWSPslCwDdUhhH4TyJIDf
iULa7SiieDphYuNhFHdCdR8wuPUxrX7NNWD9DdmPp9CiaQOTfTNvBcEhtSRY9e0h
idKAX89Muum9A+hzPcD1s9X/QZAJlidm05EtoZMisp+SLngIHMIl8dajT3EPqtBr
gbOMbNILAyLvKXojKPUe/mtNEb/x7CnX/XysIh4H+wDKJiHvav84sba8RtWnw+wP
gYhRUuhZWlu46ucrqFoOuU2JB57sJh5NAcB+21ZjKROkajGTOgNvoWw+SsqM/VvM
C5EdvnUD2IW9PumeqfWkiWtJaae0wSuGFyFgCGLiqA81lvUsBzW9TdV/Utswsdb/
7hFOB0Fom9WzdW6ATXDu7sf2LvIkyTy8g8RYm4sJa37EDBqI90dRWatDDP6Jgtou
LohE+2Cqslvd771o4vhxmIi3S/t3uEV4pOtCQynOZrqBp091IykBeW/E4BLVE75I
daq+4Vkc+Wb55GfcwBgm
=n9bx
-----END PGP SIGNATURE-----

Re: Problems with downloading from https

[Ludovic Courtès]

Alex Kost <alezost@gmail.com> skribis:

> $ guix download https://savannah.gnu.org/projects/guix/
> starting download of `/tmp/guix-file.Z7tZhy' from `https://savannah.gnu.org/projects/guix/'...
> ;;; Failed to autoload make-session in (gnutls):
> ;;; ERROR: missing interface for module (gnutls)
> ERROR: In procedure module-lookup: Unbound variable: make-session
> failed to download "/tmp/guix-file.Z7tZhy" from "https://savannah.gnu.org/projects/guix/"
> guix download: error: https://savannah.gnu.org/projects/guix/: download failed

The problem is that the GnuTLS Guile bindings must be installed for
‘guix download’ to work with HTTPS (the manual suggests it, but perhaps
not clearly enough?)

So just install GnuTLS, make sure ‘guile -c '(use-modules (gnutls))'’
succeeds, and then it’ll work.

Ludo’.

[PATCH 1/1] README: add a note about optional GnuTLS dependency.

[Ian Denhardt]

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


* README: add a note about 'guix download''s GnuTLS dependency. This is
  documented in the manual, but should be more prominently featured.
---
 README | 2 ++
 1 file changed, 2 insertions(+)


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-README-add-a-note-about-optional-GnuTLS-dependency.patch --]
[-- Type: text/x-patch; name="0001-README-add-a-note-about-optional-GnuTLS-dependency.patch", Size: 674 bytes --]

diff --git a/README b/README
index 3e9e972..8b8c05f 100644
--- a/README
+++ b/README
@@ -23,6 +23,8 @@ GNU Guix currently depends on the following packages:
   - [[http://gnu.org/software/guile/][GNU Guile 2.0.x]], version 2.0.5 or later
   - [[http://gnupg.org/][GNU libgcrypt]]
   - optionally [[http://savannah.nongnu.org/projects/guile-json/][Guile-JSON]], for the 'guix import pypi' command
+  - optionally [[http://www.gnutls.org][GnuTLS]] compiled with guile support enabled, for HTTPS support in the
+    'guix download' command. Note that 'guix import pypi' requires this functionality.
 
 Unless `--disable-daemon' was passed, the following packages are needed:
 

[PATCH 0/1] Re: Problems with downloading from https

[Ian Denhardt]

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

Quoting Ludovic Courtès (Sat, 25 Oct 2014 23:53:25 +0200)
> The problem is that the GnuTLS Guile bindings must be installed for
> ‘guix download’ to work with HTTPS (the manual suggests it, but perhaps
> not clearly enough?)

The README is probably a better place. Here's a patch.

> So just install GnuTLS, make sure ‘guile -c '(use-modules (gnutls))'’
> succeeds, and then it’ll work.

Progress, though now I'm getting cert errors (curl is happy). *sigh*


Ian Denhardt (1):
  README: add a note about optional GnuTLS dependency.

 README | 2 ++
 1 file changed, 2 insertions(+)

-- 
2.1.2

Re: Problems with downloading from https

[Alex Kost]

Ian Denhardt (2014-10-26 00:02 +0400) wrote:

> Quoting Alex Kost (2014-10-25 13:30:26)
>> Hello, I noticed <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=18831>
>> and decided to ask about a similar problem I have.
>>
>> Whenever I try to download anything from https, I get an error, for
>> example:
>>
>> --8<---------------cut here---------------start------------->8---
>> $ guix download https://savannah.gnu.org/projects/guix/
>> starting download of `/tmp/guix-file.Z7tZhy' from `https://savannah.gnu.org/projects/guix/'...
>> ;;; Failed to autoload make-session in (gnutls):
>> ;;; ERROR: missing interface for module (gnutls)
>> ERROR: In procedure module-lookup: Unbound variable: make-session
>> failed to download "/tmp/guix-file.Z7tZhy" from "https://savannah.gnu.org/projects/guix/"
>> guix download: error: https://savannah.gnu.org/projects/guix/: download failed
>> --8<---------------cut here---------------end--------------->8---
>>
>> I have a feeling that I'm missing something obvious but I can't figure
>> it out.  Any help appreciated.
>
> Huh, I assumed this was just me having set up something wrong. Either
> this is an actual bug, or we've hit the same pitfall with configuration.
>
> Do others have this working? What's your setup like? I'm running in a
> git checkout on an up-to-date Archlinux system, set up according to the
> instructions in the README.

The same for me (Arch Linux as well).  Unhappily, as you can see at
<https://projects.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/gnutls>
gnutls is built without guile support (./configure … --disable-guile).
Thus gnutls from Arch Linux wouldn't work; so I installed gnutls using
guix and augmented guile paths with:

  /home/<user>/.guix-profile/share/guile/site

With this guile can find (gnutls) module and the error disappears.


Ludovic Courtès (2014-10-26 01:53 +0400) wrote:

> The problem is that the GnuTLS Guile bindings must be installed for
> ‘guix download’ to work with HTTPS (the manual suggests it, but perhaps
> not clearly enough?)

Thanks for the explanation.  The manual is absolutely clear, I just
didn't read it properly :-)

> So just install GnuTLS, make sure ‘guile -c '(use-modules (gnutls))'’
> succeeds, and then it’ll work.

Yes, I installed gnutls, but it didn't work because I didn't set the
right guile paths: “guix package --search-paths” recommends
"/usr/local/var/guix/profiles/per-user/<user>/guix-profile/share/guile/site/2.0"
but "gnutls.scm" is actually placed in
"/usr/local/var/guix/profiles/per-user/<user>/guix-profile/share/guile/site"
so ‘(use-modules (gnutls))’ failed for me.

Perhaps “guix package --search-paths” should be adjusted to recommend
the following (?):

export GUILE_LOAD_PATH="<path/to/guix-profile>/share/guile/site/2.0:<path/to/guix-profile>/share/guile/site"
export GUILE_LOAD_COMPILED_PATH="<path/to/guix-profile>/share/guile/site/2.0:<path/to/guix-profile>/share/guile/site"

-- 
Alex

Re: Problems with downloading from https

[Ludovic Courtès]

Alex Kost <alezost@gmail.com> skribis:

> Yes, I installed gnutls, but it didn't work because I didn't set the
> right guile paths: “guix package --search-paths” recommends
> "/usr/local/var/guix/profiles/per-user/<user>/guix-profile/share/guile/site/2.0"
> but "gnutls.scm" is actually placed in
> "/usr/local/var/guix/profiles/per-user/<user>/guix-profile/share/guile/site"
> so ‘(use-modules (gnutls))’ failed for me.

Oh, that’s a bug of the GnuTLS package: we should pass the right
configure flag so that modules go to site/2.0.  Could you do that?

This should probably go to core-updates, since it’s going to be merged
soon anyway.

Thanks,
Ludo’.

Re: Problems with downloading from https

[Alex Kost]

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

Ludovic Courtès (2014-10-26 16:46 +0300) wrote:

> Alex Kost <alezost@gmail.com> skribis:
>
>> Yes, I installed gnutls, but it didn't work because I didn't set the
>> right guile paths: “guix package --search-paths” recommends
>> "/usr/local/var/guix/profiles/per-user/<user>/guix-profile/share/guile/site/2.0"
>> but "gnutls.scm" is actually placed in
>> "/usr/local/var/guix/profiles/per-user/<user>/guix-profile/share/guile/site"
>> so ‘(use-modules (gnutls))’ failed for me.
>
> Oh, that’s a bug of the GnuTLS package: we should pass the right
> configure flag so that modules go to site/2.0.  Could you do that?

Yes, but I'm a little concerned.  Should it really be so?  What about
guile-1.8; isn't it supposed to use gnutls module as well?

> This should probably go to core-updates, since it’s going to be merged
> soon anyway.

As far as I can see there is no core-updates branch currently:
<http://git.savannah.gnu.org/cgit/guix.git/refs/>.

The patch is attached, so (if it looks good to you) should I push it to
master or create "core-updates" branch?


[-- Attachment #2: 0001-gnu-gnutls-Fix-path-to-a-guile-site-directory.patch --]
[-- Type: text/x-diff, Size: 1193 bytes --]

From 8fd2d01a276f3dc7922577d1bd153677dcea4a39 Mon Sep 17 00:00:00 2001
From: Alex Kost <alezost@gmail.com>
Date: Sun, 26 Oct 2014 22:11:24 +0300
Subject: [PATCH] gnu: gnutls: Fix path to a guile site directory.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Suggested by Ludovic Courtès.

* gnu/packages/gnutls.scm (gnutls): Add '--with-guile-site-dir' configure
  flag.
---
 gnu/packages/gnutls.scm | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/gnu/packages/gnutls.scm b/gnu/packages/gnutls.scm
index 1660588..7e9b85e 100644
--- a/gnu/packages/gnutls.scm
+++ b/gnu/packages/gnutls.scm
@@ -77,6 +77,11 @@ specifications.")
                "1krx33ab2ijwfz71f1ba8labxfsic7jhlhv6rvjsyw566jj9a3d2"))
              (patches (list (search-patch "gnutls-server-name-fix.patch")))))
     (build-system gnu-build-system)
+    (arguments
+     '(#:configure-flags
+       (list (string-append "--with-guile-site-dir="
+                            (assoc-ref %outputs "out")
+                            "/share/guile/site/2.0"))))
     (native-inputs
      `(("pkg-config" ,pkg-config)))
     (inputs
-- 
2.1.2

Re: Problems with downloading from https

[Ludovic Courtès]

Alex Kost <alezost@gmail.com> skribis:

> Ludovic Courtès (2014-10-26 16:46 +0300) wrote:
>
>> Alex Kost <alezost@gmail.com> skribis:
>>
>>> Yes, I installed gnutls, but it didn't work because I didn't set the
>>> right guile paths: “guix package --search-paths” recommends
>>> "/usr/local/var/guix/profiles/per-user/<user>/guix-profile/share/guile/site/2.0"
>>> but "gnutls.scm" is actually placed in
>>> "/usr/local/var/guix/profiles/per-user/<user>/guix-profile/share/guile/site"
>>> so ‘(use-modules (gnutls))’ failed for me.
>>
>> Oh, that’s a bug of the GnuTLS package: we should pass the right
>> configure flag so that modules go to site/2.0.  Could you do that?
>
> Yes, but I'm a little concerned.  Should it really be so?  What about
> guile-1.8; isn't it supposed to use gnutls module as well?

1.8 has long been deprecated, so let’s not worry about it.

>> This should probably go to core-updates, since it’s going to be merged
>> soon anyway.
>
> As far as I can see there is no core-updates branch currently:
> <http://git.savannah.gnu.org/cgit/guix.git/refs/>.

Ah yes, it was actually merged earlier today.

> The patch is attached, so (if it looks good to you) should I push it to
> master or create "core-updates" branch?

Looks good, please push to ‘master’.

Thanks,
Ludo’.

Re: Problems with downloading from https

[Mark H Weaver]

ludo@gnu.org (Ludovic Courtès) writes:

> Alex Kost <alezost@gmail.com> skribis:
>
>> Ludovic Courtès (2014-10-26 16:46 +0300) wrote:
>>
>>> Alex Kost <alezost@gmail.com> skribis:
>>>
>>>> Yes, I installed gnutls, but it didn't work because I didn't set the
>>>> right guile paths: “guix package --search-paths” recommends
>>>> "/usr/local/var/guix/profiles/per-user/<user>/guix-profile/share/guile/site/2.0"
>>>> but "gnutls.scm" is actually placed in
>>>> "/usr/local/var/guix/profiles/per-user/<user>/guix-profile/share/guile/site"
>>>> so ‘(use-modules (gnutls))’ failed for me.
>>>
>>> Oh, that’s a bug of the GnuTLS package: we should pass the right
>>> configure flag so that modules go to site/2.0.  Could you do that?

Alex committed this change, and it broke all https downloads in Guix,
leading to hydra build failures.  For example, see:

  http://hydra.gnu.org/build/132928/nixlog/1/raw

The reason is that guix/download.scm contains this code:

--8<---------------cut here---------------start------------->8---
              ;; Add GnuTLS to the inputs and to the load path.
              #~(eval-when (load expand eval)
                  (set! %load-path
                        (cons (string-append #$(gnutls-package)
                                             "/share/guile/site")
                              %load-path)))
              #~#t)
--8<---------------cut here---------------end--------------->8---

For now, I think we should revert this commit and discuss it further
before proceeding.

>> Yes, but I'm a little concerned.  Should it really be so?  What about
>> guile-1.8; isn't it supposed to use gnutls module as well?
>
> 1.8 has long been deprecated, so let’s not worry about it.

I think Alex was right to be concerned.  We'll have the same problem
when Guile 2.2 comes around, and then again for 2.4.  I'm reluctant to
hardcode "2.0" into the code above.  Think about what it implies for
GnuTLS in the future.  Will they be expected to install their modules
into site/2.0, site/2.2, site/2.4, etc?  Do we really want to advocate
this practice to projects that install Guile modules?

       Mark

Re: [PATCH 0/1] Re: Problems with downloading from https

[Ian Denhardt]

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

Ping. Haven't heard anything about this.

Quoting Ian Denhardt (2014-10-26 01:30:05)
> Quoting Ludovic Courtès (Sat, 25 Oct 2014 23:53:25 +0200)
> > The problem is that the GnuTLS Guile bindings must be installed for
> > ‘guix download’ to work with HTTPS (the manual suggests it, but perhaps
> > not clearly enough?)
> 
> The README is probably a better place. Here's a patch.
> 
> > So just install GnuTLS, make sure ‘guile -c '(use-modules (gnutls))'’
> > succeeds, and then it’ll work.
> 
> Progress, though now I'm getting cert errors (curl is happy). *sigh*
> 
> 
> Ian Denhardt (1):
>   README: add a note about optional GnuTLS dependency.
> 
>  README | 2 ++
>  1 file changed, 2 insertions(+)
> 
> -- 
> 2.1.2

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAABAgAGBQJUTiMhAAoJEPZUuMfUyjy46PAP/1PH4hejKX6+Yvdx/y3vevni
PSg9rEtT4mQ6fiRfG4t16iPPoCDSYP7TN3RP52XbYGFDCTh6RDnkbOij3jiJuCbf
6165oe0U2/PJgzZ+ovgjeZwbgyOvNmTNIv3WWpZ2JhKvBCNcOrKvbxXtuvGtDQui
MM3ZrUMKaJ9azoaTrsMlQUPVRR87tmCt0zlJpruoQq+DCvVP57RajwvEvu1Y+qi4
sRomiu68pDFGdMm1vwcfWnIJon80t8VtaRS6mJjiZOOJoaqXeEe0O9j2ePF0DDa+
IkaSYpXtW2aSqbUqdgeoCi8Uz359eIyfaCsTE79dFMajtVJkep4jGi8S1fAwc+ou
x/rnah7C5PPo3Vyx2Uk0paVFsLQlQAhMK97VoF6yYXPMcZLh3jeDWYcXQJchVkJi
P1mI4Xf5My2Qtuw0zi3EviRiHQEvrhEt2GovwEDb5W4gJI61dNPgUeDNsww84+Tu
nxdG5pP70bK7gFA1lj/lIDIDXSnbEolxRPMdPcz2OtjTx+mRO80BmTpfGFgJcMNb
q0eCPjbn5ghaVpXdsgq8bzBjDKU+ib6AWZEmvHtXB1rnBoriNhybhynLEGRw5fFe
4VcXuq9KawX0TP3UBsWbgxcG78epUpO9FDurs3jChGHDLzKJJS0YTSK5ylfRu6LI
5NkB+j5XuThcFAgiobZ+
=LVAC
-----END PGP SIGNATURE-----

Re: Problems with downloading from https

[Ludovic Courtès]

Mark H Weaver <mhw@netris.org> skribis:

> ludo@gnu.org (Ludovic Courtès) writes:
>
>> Alex Kost <alezost@gmail.com> skribis:
>>
>>> Ludovic Courtès (2014-10-26 16:46 +0300) wrote:
>>>
>>>> Alex Kost <alezost@gmail.com> skribis:
>>>>
>>>>> Yes, I installed gnutls, but it didn't work because I didn't set the
>>>>> right guile paths: “guix package --search-paths” recommends
>>>>> "/usr/local/var/guix/profiles/per-user/<user>/guix-profile/share/guile/site/2.0"
>>>>> but "gnutls.scm" is actually placed in
>>>>> "/usr/local/var/guix/profiles/per-user/<user>/guix-profile/share/guile/site"
>>>>> so ‘(use-modules (gnutls))’ failed for me.
>>>>
>>>> Oh, that’s a bug of the GnuTLS package: we should pass the right
>>>> configure flag so that modules go to site/2.0.  Could you do that?
>
> Alex committed this change, and it broke all https downloads in Guix,
> leading to hydra build failures.  For example, see:
>
>   http://hydra.gnu.org/build/132928/nixlog/1/raw
>
> The reason is that guix/download.scm contains this code:
>
>               ;; Add GnuTLS to the inputs and to the load path.
>               #~(eval-when (load expand eval)
>                   (set! %load-path
>                         (cons (string-append #$(gnutls-package)
>                                              "/share/guile/site")
>                               %load-path)))
>               #~#t)

Oops, my bad.  I think this code should be changed to use site/2.0,
which is the standard search path specification.

> For now, I think we should revert this commit and discuss it further
> before proceeding.

I would just fix the above code to append (effective-version).  WDYT?

>>> Yes, but I'm a little concerned.  Should it really be so?  What about
>>> guile-1.8; isn't it supposed to use gnutls module as well?
>>
>> 1.8 has long been deprecated, so let’s not worry about it.
>
> I think Alex was right to be concerned.  We'll have the same problem
> when Guile 2.2 comes around, and then again for 2.4.  I'm reluctant to
> hardcode "2.0" into the code above.  Think about what it implies for
> GnuTLS in the future.  Will they be expected to install their modules
> into site/2.0, site/2.2, site/2.4, etc?  Do we really want to advocate
> this practice to projects that install Guile modules?

No, you’re right, of course.  However, I tend to distinguish between the
immediate issue that calls for a fix, and the design issue that has to
be addressed, but is less pressing.

Currently, there are a couple of packages that hard-code site/2.0.  They
should be changed to use:

  (string-append "--with-site-dir=.../site/" (effective-version))

That doesn’t help with 1.8, though, because 1.8 uses /site.  Perhaps a
fix would be to change 1.8 in Guix so that it uses a versioned site
directory like future versions do?  Another option would be to ignore 1.8.

WDYT?

There may be similar problems with Python, Ruby, etc., although these
haven’t come up yet, I think.  These can hopefully be addressed by
having their respective build system pass #:effective-version to the
build code.  Thoughts?

Thanks,
Ludo’.

Re: Problems with downloading from https

[Ludovic Courtès]

ludo@gnu.org (Ludovic Courtès) skribis:

> Currently, there are a couple of packages that hard-code site/2.0.  They
> should be changed to use:
>
>   (string-append "--with-site-dir=.../site/" (effective-version))

Actually this won’t work because the Guile that runs the build script is
not necessarily the same as the one used to build the thing.

So we probably need a helper function in (guix build utils) that runs
“guile -c '(display (effective-version))'” and returns that.

How does that sound?

Ludo’.

Re: [PATCH 1/1] README: add a note about optional GnuTLS dependency.

[Ludovic Courtès]

Ian Denhardt <ian@zenhack.net> skribis:

> * README: add a note about 'guix download''s GnuTLS dependency. This is
>   documented in the manual, but should be more prominently featured.

Thanks.  Pushed with a similar change in guix.texi.

Ludo’.

Re: Problems with downloading from https

[Alex Kost]

Mark H Weaver (2014-10-27 12:06 +0300) wrote:

> ludo@gnu.org (Ludovic Courtès) writes:
>
>> Alex Kost <alezost@gmail.com> skribis:
>>
>>> Ludovic Courtès (2014-10-26 16:46 +0300) wrote:
>>>
>>>> Alex Kost <alezost@gmail.com> skribis:
>>>>
>>>>> Yes, I installed gnutls, but it didn't work because I didn't set the
>>>>> right guile paths: “guix package --search-paths” recommends
>>>>> "/usr/local/var/guix/profiles/per-user/<user>/guix-profile/share/guile/site/2.0"
>>>>> but "gnutls.scm" is actually placed in
>>>>> "/usr/local/var/guix/profiles/per-user/<user>/guix-profile/share/guile/site"
>>>>> so ‘(use-modules (gnutls))’ failed for me.
>>>>
>>>> Oh, that’s a bug of the GnuTLS package: we should pass the right
>>>> configure flag so that modules go to site/2.0.  Could you do that?
>
> Alex committed this change, and it broke all https downloads in Guix,
> leading to hydra build failures.  For example, see:
>
>   http://hydra.gnu.org/build/132928/nixlog/1/raw

[...]

OMG!  I'm sorry about that.  And thanks for fixing imlib2 license issue.

I'm feeling guilty and I think I shouldn't touch anything outside
"emacs" directory.  Sorry again.

-- 
Alex

Re: Problems with downloading from https

[Alex Kost]

Ludovic Courtès (2014-10-27 15:24 +0300) wrote:

> Mark H Weaver <mhw@netris.org> skribis:
>
>> ludo@gnu.org (Ludovic Courtès) writes:
>>
>>> Alex Kost <alezost@gmail.com> skribis:
>>>
>>>> Ludovic Courtès (2014-10-26 16:46 +0300) wrote:
>>>>
>>>>> Alex Kost <alezost@gmail.com> skribis:
>>>>>
>>>>>> Yes, I installed gnutls, but it didn't work because I didn't set the
>>>>>> right guile paths: “guix package --search-paths” recommends
>>>>>> "/usr/local/var/guix/profiles/per-user/<user>/guix-profile/share/guile/site/2.0"
>>>>>> but "gnutls.scm" is actually placed in
>>>>>> "/usr/local/var/guix/profiles/per-user/<user>/guix-profile/share/guile/site"
>>>>>> so ‘(use-modules (gnutls))’ failed for me.
>>>>>
>>>>> Oh, that’s a bug of the GnuTLS package: we should pass the right
>>>>> configure flag so that modules go to site/2.0.  Could you do that?
>>
>> Alex committed this change, and it broke all https downloads in Guix,
>> leading to hydra build failures.  For example, see:
>>
>>   http://hydra.gnu.org/build/132928/nixlog/1/raw
>>
>> The reason is that guix/download.scm contains this code:
>>
>>               ;; Add GnuTLS to the inputs and to the load path.
>>               #~(eval-when (load expand eval)
>>                   (set! %load-path
>>                         (cons (string-append #$(gnutls-package)
>>                                              "/share/guile/site")
>>                               %load-path)))
>>               #~#t)
>
> Oops, my bad.  I think this code should be changed to use site/2.0,
> which is the standard search path specification.
>
>> For now, I think we should revert this commit and discuss it further
>> before proceeding.
>
> I would just fix the above code to append (effective-version).  WDYT?
>
>>>> Yes, but I'm a little concerned.  Should it really be so?  What about
>>>> guile-1.8; isn't it supposed to use gnutls module as well?
>>>
>>> 1.8 has long been deprecated, so let’s not worry about it.
>>
>> I think Alex was right to be concerned.  We'll have the same problem
>> when Guile 2.2 comes around, and then again for 2.4.  I'm reluctant to
>> hardcode "2.0" into the code above.  Think about what it implies for
>> GnuTLS in the future.  Will they be expected to install their modules
>> into site/2.0, site/2.2, site/2.4, etc?  Do we really want to advocate
>> this practice to projects that install Guile modules?
>
> No, you’re right, of course.  However, I tend to distinguish between the
> immediate issue that calls for a fix, and the design issue that has to
> be addressed, but is less pressing.
>
> Currently, there are a couple of packages that hard-code site/2.0.  They
> should be changed to use:
>
>   (string-append "--with-site-dir=.../site/" (effective-version))
>
> That doesn’t help with 1.8, though, because 1.8 uses /site.  Perhaps a
> fix would be to change 1.8 in Guix so that it uses a versioned site
> directory like future versions do?  Another option would be to ignore 1.8.
>
> WDYT?
>
> There may be similar problems with Python, Ruby, etc., although these
> haven’t come up yet, I think.  These can hopefully be addressed by
> having their respective build system pass #:effective-version to the
> build code.  Thoughts?

Why not just allow gnutls and other packages to install guile modules in
a site dir (without version) and to augment GUILE_LOAD_PATH with it as I
suggested at
<http://lists.gnu.org/archive/html/guix-devel/2014-10/msg00333.html>?

-- 
Alex

Re: Problems with downloading from https

[Mark H Weaver]

Alex Kost <alezost@gmail.com> writes:

> Mark H Weaver (2014-10-27 12:06 +0300) wrote:
>
>> ludo@gnu.org (Ludovic Courtès) writes:
>>
>>> Alex Kost <alezost@gmail.com> skribis:
>>>
>>>> Ludovic Courtès (2014-10-26 16:46 +0300) wrote:
>>>>
>>>>> Alex Kost <alezost@gmail.com> skribis:
>>>>>
>>>>>> Yes, I installed gnutls, but it didn't work because I didn't set the
>>>>>> right guile paths: “guix package --search-paths” recommends
>>>>>> "/usr/local/var/guix/profiles/per-user/<user>/guix-profile/share/guile/site/2.0"
>>>>>> but "gnutls.scm" is actually placed in
>>>>>> "/usr/local/var/guix/profiles/per-user/<user>/guix-profile/share/guile/site"
>>>>>> so ‘(use-modules (gnutls))’ failed for me.
>>>>>
>>>>> Oh, that’s a bug of the GnuTLS package: we should pass the right
>>>>> configure flag so that modules go to site/2.0.  Could you do that?
>>
>> Alex committed this change, and it broke all https downloads in Guix,
>> leading to hydra build failures.  For example, see:
>>
>>   http://hydra.gnu.org/build/132928/nixlog/1/raw
>
> [...]
>
> OMG!  I'm sorry about that.  And thanks for fixing imlib2 license issue.
>
> I'm feeling guilty and I think I shouldn't touch anything outside
> "emacs" directory.  Sorry again.

No, not at all!  We all very much appreciate your contributions, Alex,
and you only did what Ludovic asked you to do.  Anyway, it's not as
though a few missing builds on Hydra is the end of the world.  That
happens quite regularly anyway, so please don't worry about it.

      Mark

Re: Problems with downloading from https

[Mark H Weaver]

Alex Kost <alezost@gmail.com> writes:

> Why not just allow gnutls and other packages to install guile modules in
> a site dir (without version) and to augment GUILE_LOAD_PATH with it as I
> suggested at
> <http://lists.gnu.org/archive/html/guix-devel/2014-10/msg00333.html>?

In my opinion, this is the right fix.  There is plenty of Guile code
that works on both Guile 1.8 and Guile 2.0, so there's no need to put
Scheme modules in versioned directories.  We provide 'cond-expand' when
it's really needed, after all.

Guile 2 puts both "site/2.0" and "site" in its load path by default,
which signals to developers that they can choose either location.

Furthermore, if changing the installation directory of the GnuTLS
modules broke Guix, there's a non-trivial possibility that we might
break something else.

Please, let's leave the GnuTLS modules where they are, and add "site" to
the search-path-specification, as Alex suggests.

What do you think?

      Mark

Re: Problems with downloading from https

[Ludovic Courtès]

Mark H Weaver <mhw@netris.org> skribis:

> Alex Kost <alezost@gmail.com> writes:
>
>> Why not just allow gnutls and other packages to install guile modules in
>> a site dir (without version) and to augment GUILE_LOAD_PATH with it as I
>> suggested at
>> <http://lists.gnu.org/archive/html/guix-devel/2014-10/msg00333.html>?
>
> In my opinion, this is the right fix.  There is plenty of Guile code
> that works on both Guile 1.8 and Guile 2.0, so there's no need to put
> Scheme modules in versioned directories.  We provide 'cond-expand' when
> it's really needed, after all.

A problem is that it would make it impossible to install the 1.8/2.1 and
the 2.0 version of something in the same profile.

Currently it’s possible to install both ‘python’ and ‘python2’ in the
same profile, as well as ‘python-foo’ and ‘python2-foo’.

With the addition of a --program-suffix configure flag, it would be
possible to do the same with Guile 1.8/2.0/2.1.

I think it’s a useful feature.  WDYT?

> Furthermore, if changing the installation directory of the GnuTLS
> modules broke Guix, there's a non-trivial possibility that we might
> break something else.

Given that the search path spec for guile-2.0 has always been site/2.0,
I think this change is unlikely to break anything else.  On the
contrary: this change brought GnuTLS in conformance with the other
Guile-using packages.

Thanks,
Ludo’.

Re: Problems with downloading from https

[Alex Kost]

Ludovic Courtès (2014-10-27 19:24 +0300) wrote:

> Mark H Weaver <mhw@netris.org> skribis:
>
>> Alex Kost <alezost@gmail.com> writes:
>>
>>> Why not just allow gnutls and other packages to install guile modules in
>>> a site dir (without version) and to augment GUILE_LOAD_PATH with it as I
>>> suggested at
>>> <http://lists.gnu.org/archive/html/guix-devel/2014-10/msg00333.html>?
>>
>> In my opinion, this is the right fix.  There is plenty of Guile code
>> that works on both Guile 1.8 and Guile 2.0, so there's no need to put
>> Scheme modules in versioned directories.  We provide 'cond-expand' when
>> it's really needed, after all.
>
> A problem is that it would make it impossible to install the 1.8/2.1 and
> the 2.0 version of something in the same profile.
>
> Currently it’s possible to install both ‘python’ and ‘python2’ in the
> same profile, as well as ‘python-foo’ and ‘python2-foo’.

[...]

But currently it's not possible to install 2 (or more) packages with the
same name.  So a user can't have guile 2.0 and guile 1.8 in the same
profile.  The same thing with python: there is no ‘python2’ package.
Both python packages have “python” name and can't be installed in the
same profile, as far as I understand.

-- 
Alex

Re: Problems with downloading from https

[Ludovic Courtès]

Alex Kost <alezost@gmail.com> skribis:

> Ludovic Courtès (2014-10-27 19:24 +0300) wrote:
>
>> Mark H Weaver <mhw@netris.org> skribis:
>>
>>> Alex Kost <alezost@gmail.com> writes:
>>>
>>>> Why not just allow gnutls and other packages to install guile modules in
>>>> a site dir (without version) and to augment GUILE_LOAD_PATH with it as I
>>>> suggested at
>>>> <http://lists.gnu.org/archive/html/guix-devel/2014-10/msg00333.html>?
>>>
>>> In my opinion, this is the right fix.  There is plenty of Guile code
>>> that works on both Guile 1.8 and Guile 2.0, so there's no need to put
>>> Scheme modules in versioned directories.  We provide 'cond-expand' when
>>> it's really needed, after all.
>>
>> A problem is that it would make it impossible to install the 1.8/2.1 and
>> the 2.0 version of something in the same profile.
>>
>> Currently it’s possible to install both ‘python’ and ‘python2’ in the
>> same profile, as well as ‘python-foo’ and ‘python2-foo’.
>
> [...]
>
> But currently it's not possible to install 2 (or more) packages with the
> same name.  So a user can't have guile 2.0 and guile 1.8 in the same
> profile.  The same thing with python: there is no ‘python2’ package.
> Both python packages have “python” name and can't be installed in the
> same profile, as far as I understand.

Good point! (Somehow I thought there was ‘python2’.)

I don’t know if I’m in an over-engineering mindset or something ;-), but
I still feel keeping versioned directory is more flexible.

After all, parallel installability (info "(guile) Parallel
Installations") is initially intended to solve issues for FHS-style
systems.  Guix has other ways to deal with that.  But still, the same
kind of problems arise when mixing things in a Guix build environment or
profile.

Ludo’.

Re: Problems with downloading from https

[Andreas Enge]

On Tue, Oct 28, 2014 at 09:03:44AM +0100, Ludovic Courtès wrote:
> Alex Kost <alezost@gmail.com> skribis:
> > But currently it's not possible to install 2 (or more) packages with the
> > same name.  So a user can't have guile 2.0 and guile 1.8 in the same
> > profile.  The same thing with python: there is no ‘python2’ package.
> > Both python packages have “python” name and can't be installed in the
> > same profile, as far as I understand.
> 
> Good point! (Somehow I thought there was ‘python2’.)

Is it really not possible to install two packages with the same name?
I thought you could do
   guix package -i python python-2.7.6
where the first one will chose the latest package? It just requires that
there are no overlapping paths.

Andreas

Re: Problems with downloading from https

[Alex Kost]

Andreas Enge (2014-10-30 01:22 +0300) wrote:

> On Tue, Oct 28, 2014 at 09:03:44AM +0100, Ludovic Courtès wrote:
>> Alex Kost <alezost@gmail.com> skribis:
>> > But currently it's not possible to install 2 (or more) packages with the
>> > same name.  So a user can't have guile 2.0 and guile 1.8 in the same
>> > profile.  The same thing with python: there is no ‘python2’ package.
>> > Both python packages have “python” name and can't be installed in the
>> > same profile, as far as I understand.
>> 
>> Good point! (Somehow I thought there was ‘python2’.)
>
> Is it really not possible to install two packages with the same name?
> I thought you could do
>    guix package -i python python-2.7.6
> where the first one will chose the latest package? It just requires that
> there are no overlapping paths.

I think such an "evil" case is just not handled currently.  If you have
python-3… installed and you install python-2… in the same profile, then
python-3… would be replaced, but if you install both packages in the
same command, then both would be installed.  It's OK for pythons,
because there are no name collisions in these packages, but if you try
to install both "guile-2.0.11" and "guile-1.8.8" is such a way, then you
will have several collisions.

So I think installing packages with the same name in one transaction
should also be prohibited.

As both python packages can co-exist in one profile, either python-2…
may be renamed into “python2” or python-3… into “python3”.  As python3
is the future, I think it would be better to have “python2” and “python”
(which is python3) packages.  Or maybe they shouldn't be renamed and we
can introduce a little collision instead by adding "…/bin/python"
symlink to python-3… package.

Re: Problems with downloading from https

[Andreas Enge]

On Thu, Oct 30, 2014 at 10:27:59AM +0300, Alex Kost wrote:
> I think such an "evil" case is just not handled currently.  If you have
> python-3… installed and you install python-2… in the same profile, then
> python-3… would be replaced, but if you install both packages in the
> same command, then both would be installed.

Interesting, I did not know this, but you are right:

$ guix package -i python
$ guix package -i python-2.7.6
The following package will be upgraded:
   python       3.3.5 → 2.7.6   /gnu/store/iz5shg4py68mbccv2kkd0siv6ryfl3y1-python-2.7.6

If you do instead
$ guix package -i python python-2.7.6

both packages are installed.

I think the former behaviour is a bug. If I use "-i" and not "-u", a package
should not be "upgraded", but added in every case, independently of its name.

Andreas

Re: Problems with downloading from https

[Alex Kost]

Andreas Enge (2014-10-30 10:49 +0300) wrote:

> On Thu, Oct 30, 2014 at 10:27:59AM +0300, Alex Kost wrote:
>> I think such an "evil" case is just not handled currently.  If you have
>> python-3… installed and you install python-2… in the same profile, then
>> python-3… would be replaced, but if you install both packages in the
>> same command, then both would be installed.
>
> Interesting, I did not know this, but you are right:
>
> $ guix package -i python
> $ guix package -i python-2.7.6
> The following package will be upgraded:
>    python       3.3.5 → 2.7.6   /gnu/store/iz5shg4py68mbccv2kkd0siv6ryfl3y1-python-2.7.6
>
> If you do instead
> $ guix package -i python python-2.7.6
>
> both packages are installed.
>
> I think the former behaviour is a bug. If I use "-i" and not "-u", a package
> should not be "upgraded", but added in every case, independently of its name.

I think the latter is a bug.  IMHO it shouldn't be possible to install
several packages with the same name in one profile.

-- 
Alex

Re: Problems with downloading from https

[Andreas Enge]

On Thu, Oct 30, 2014 at 03:31:15PM +0300, Alex Kost wrote:
> I think the latter is a bug.  IMHO it shouldn't be possible to install
> several packages with the same name in one profile.

Well, having python 2 and 3 is reasonable, and from what I saw in their
naming scheme, it is entirely possible (the python binary being renamed
to python 3). Qt 4 and 5 are, I think, another case. How about GTK+ 2 and 3?

Of course we could rename the packages, but this is not our policy so far.

Andreas

Re: Problems with downloading from https

[Ludovic Courtès]

Alex Kost <alezost@gmail.com> skribis:

> I think such an "evil" case is just not handled currently.  If you have
> python-3… installed and you install python-2… in the same profile, then
> python-3… would be replaced, but if you install both packages in the
> same command, then both would be installed.

Oh, really?  This must be a bug in ‘manifest-transaction-effects’ then, no?

Ludo’.

Re: Problems with downloading from https

[Ludovic Courtès]

ludo@gnu.org (Ludovic Courtès) skribis:

> Mark H Weaver <mhw@netris.org> skribis:

[...]

>> The reason is that guix/download.scm contains this code:
>>
>>               ;; Add GnuTLS to the inputs and to the load path.
>>               #~(eval-when (load expand eval)
>>                   (set! %load-path
>>                         (cons (string-append #$(gnutls-package)
>>                                              "/share/guile/site")
>>                               %load-path)))
>>               #~#t)
>
> Oops, my bad.  I think this code should be changed to use site/2.0,
> which is the standard search path specification.
>
>> For now, I think we should revert this commit and discuss it further
>> before proceeding.
>
> I would just fix the above code to append (effective-version).  WDYT?

Commit e0ea3f8 does that.

(We should keep discussing the more general issue though, of course.)

Ludo’.

Re: Problems with downloading from https

[Ian Denhardt]

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

Quoting Alex Kost (2014-10-30 03:27:59)
> As both python packages can co-exist in one profile, either python-2…
> may be renamed into “python2” or python-3… into “python3”.  As python3
> is the future, I think it would be better to have “python2” and “python”
> (which is python3) packages.  Or maybe they shouldn't be renamed and we
> can introduce a little collision instead by adding "…/bin/python"
> symlink to python-3… package.

Speaking as someone who's been on a distro that has python 3 as the
default since 2.7 came out, and being a professional python developer
working on codebases that often don't work on python 3, I don't really
consider this a sensible default. I often have a symlink ahead of the
system python binary in my path that points to python2. More
importantly, I think it should be tunable. I *do* sometimes make use of
having both available.

-Ian

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAABAgAGBQJUUm/lAAoJEPZUuMfUyjy4EH8P/iQjaEBNMk8Aj0t96DdZMReN
p/DgGL3phsva9lvoN5PGHKyPaMMtyj2MU3npVNmZP10uwg7qSO0RE0LUktluLuIJ
pDrrQje/Bg6KwI4bHXbTlgl4oUDwOD+tA1JKUK3tSM3vEZF5IONNbUM9rPbkyXX7
hkNtYXLq200E7Og00NcyrFuNA2xLCVvFKMjI6FzmcjOpwiK9wscLk2pmjePUvjmd
3L5HuweZ+HSymRtg19RCZLNXYzkcQ4v6HnPldvkEVvGl7HpmB9hA4ikrBOyvWc52
Cb2/sXYEh92kbWGuOGeI67yFtbpqx4j1nkB9G+1ym3CHAyMqZ3QRHxrTueFuPmy2
NYLy03N5c68dLDaV0FWFs5CcKPTl34QX3bqMXOn9DRsnRSHO4BTt7Htzm/yaCYNo
FGcC7n1CvaXKJ6zjZQ0tCrXZ7zelLbImXr+piePWDG3kyX8jXKFtxu+5r0mWJVoL
g+PxbZbzk40t6paBYrSe+lai/Jc43ttg8mmQv+Drsm/ePsW8NJ7IrcoRoBCYsw55
CGSHTzytPHh4jTeriqvBnvWvMg6MKb7ie71hHSI13Xm9rh3SEvMGVhlOiyLfv78b
3b9djhCcHEzKh423AQa4TraPCf/AW2ulzkSRqLlNTQS7BE1p6Uzcy8DjCZezSIFk
rXbXRTg/2kIVgV67GC6P
=Pbk9
-----END PGP SIGNATURE-----

Re: Problems with downloading from https

[Alex Kost]

Ian Denhardt (2014-10-30 20:05 +0300) wrote:

> Quoting Alex Kost (2014-10-30 03:27:59)
>> As both python packages can co-exist in one profile, either python-2…
>> may be renamed into “python2” or python-3… into “python3”.  As python3
>> is the future, I think it would be better to have “python2” and “python”
>> (which is python3) packages.  Or maybe they shouldn't be renamed and we
>> can introduce a little collision instead by adding "…/bin/python"
>> symlink to python-3… package.
>
> Speaking as someone who's been on a distro that has python 3 as the
> default since 2.7 came out, and being a professional python developer
> working on codebases that often don't work on python 3, I don't really
> consider this a sensible default. I often have a symlink ahead of the
> system python binary in my path that points to python2. More
> importantly, I think it should be tunable. I *do* sometimes make use of
> having both available.

This is what you currently have: you can install both, and "python" would
be a link to "python2".

But installing 2 packages with the same name is not intended (to prevent
file names collision), so I think it would be better to rename one of the
pythons into "python2"/"python3".

-- 
Alex

Re: Problems with downloading from https

[Alex Kost]

Andreas Enge (2014-10-30 15:38 +0300) wrote:

> On Thu, Oct 30, 2014 at 03:31:15PM +0300, Alex Kost wrote:
>> I think the latter is a bug.  IMHO it shouldn't be possible to install
>> several packages with the same name in one profile.
>
> Well, having python 2 and 3 is reasonable, and from what I saw in their
> naming scheme, it is entirely possible (the python binary being renamed
> to python 3). Qt 4 and 5 are, I think, another case. How about GTK+ 2 and 3?
>
> Of course we could rename the packages, but this is not our policy so far.

Actually I thought it was the policy.  I asked about that: search for
"intended" at
<http://lists.gnu.org/archive/html/guix-devel/2014-08/msg00047.html>.

Such behavior is handled by ‘manifest-add’ currently.  Before that this
code was placed in “guix/scripts/package.scm” and it was there for a
I-don't-know-how-long time.

-- 
Alex

Different versions of a package in the same profile?

[Ludovic Courtès]

Andreas Enge <andreas@enge.fr> skribis:

> On Thu, Oct 30, 2014 at 03:31:15PM +0300, Alex Kost wrote:
>> I think the latter is a bug.  IMHO it shouldn't be possible to install
>> several packages with the same name in one profile.
>
> Well, having python 2 and 3 is reasonable, and from what I saw in their
> naming scheme, it is entirely possible (the python binary being renamed
> to python 3). Qt 4 and 5 are, I think, another case. How about GTK+ 2 and 3?

Actually, Qt 4 and 5 use non-versioned file names under bin/.

Technically it would be easy to allow the installation of different
versions of a package in the same profile, but I wonder about the
implications.

For instance, ‘-u foo’ would upgrade all the installed versions of
‘foo’, so you would end up with exactly the same version twice.

Ludo’.

Re: Problems with downloading from https

[Ian Denhardt]

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

Quoting Alex Kost (2014-10-30 15:08:08)
> This is what you currently have: you can install both, and "python" would
> be a link to "python2".
> 
> But installing 2 packages with the same name is not intended (to prevent
> file names collision), so I think it would be better to rename one of the
> pythons into "python2"/"python3".

Yeah, I understood. I'd been thinking it would be nice to be able to
tune which one.

It actually wouldn't be a matter of "renaming" anything, so much as
getting rid of the symlink from one package -- on my arch system for
example,

* /usr/bin/python is a symlink to /usr/bin/python3
* /usr/bin/python3 is a symlink to /usr/bin/python3.4

In any case, I don't feel terribly strongly, but it feels like it
shouldn't be that hard to get the target of that symlink to be
user/sysadmin-configurable.

-Ian

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAABAgAGBQJUUxX0AAoJEPZUuMfUyjy4ojwQALb9IZgE3E5wP+0TvYCLSp14
bBbDvyCaMjP49uWR81ZAzsz7YRIMQPEaiZmVU3wxnPeMBRmWlUGqFJcFD1hdMkRe
ot9TeSZFLOWFPdwNLNw2lD9+H9ieBgToNNSsFCKDhsxXgm56C+SkglHSV6cgdsnb
eNiOyYrCVbES5zuU2HX8CE4YgERKB0KBFsKy99Vx3sZMs0tt8m+xc1+QoF3NsJH/
Fd829LMLkMdKlzTs75aezwQa2rfETGRG7O+ufLDxJA8biECgxOBp5saN7MKPbkbC
RN1v5t/NZJ3nhKuhXLqQ77iX1X/aFVfWJmg0NFQzD7Rq4C9H5mGRfvHNwUCz/RBB
Y7I2aX1Xfr81rOr/DHjkIo5fy1mLBNN4USedXnof1xU7NFe0u3AUbD6KH5fTeU2e
s8AlmDlnvdCdDmz18aK8ld19mlkodUp7B9eOZqcXKxEF8TROuUfUyFQAHy5woLy2
v7K/FsDwTgjogQL0Sg5t1m3XB+KLU7wqhVYe7KQJHyMyCtHcCQqDfwKkBU5YnkGA
PL8NsbKuaa1/8gMmSXF1Jb93KbTp/vbJvjPVb20m/eocJCDnzITK4CgEmOB+oHtj
sEgR+obJL5LNldrAfUSzSJZ+LLV22OwV0iqDu43nwU99mOSAbRboVsDt+fZSrHd4
TXwVgLu3wUkKVY9u7U75
=Yq4T
-----END PGP SIGNATURE-----

Re: Different versions of a package in the same profile?

[Andreas Enge]

On Fri, Oct 31, 2014 at 12:07:14AM +0100, Ludovic Courtès wrote:
> Technically it would be easy to allow the installation of different
> versions of a package in the same profile, but I wonder about the
> implications.
> 
> For instance, ‘-u foo’ would upgrade all the installed versions of
> ‘foo’, so you would end up with exactly the same version twice.

Good catch (or rather "bad feature"?).

So should we indeed rename version 2 of the python package to python2, to
allow easy installation together with python version 3?

We could do the same for Qt, but if anyway versions 4 and 5 are not
installable together, there does not seem to be a need.

How about guile?

In any case, the outcome of installation should not depend on whether we
do them in one or in several commands.

Another idea: How about letting "guix package -u foo" upgrade only the
package with name foo and the latest version if there are several with the
same name?

Andreas

Re: Different versions of a package in the same profile?

[Ludovic Courtès]

Andreas Enge <andreas@enge.fr> skribis:

> On Fri, Oct 31, 2014 at 12:07:14AM +0100, Ludovic Courtès wrote:
>> Technically it would be easy to allow the installation of different
>> versions of a package in the same profile, but I wonder about the
>> implications.
>> 
>> For instance, ‘-u foo’ would upgrade all the installed versions of
>> ‘foo’, so you would end up with exactly the same version twice.
>
> Good catch (or rather "bad feature"?).
>
> So should we indeed rename version 2 of the python package to python2, to
> allow easy installation together with python version 3?
>
> We could do the same for Qt, but if anyway versions 4 and 5 are not
> installable together, there does not seem to be a need.

I don’t think so.  In this thread, I rather wanted to discuss the
implications of allowing same-named packages to be installed in the same
profile, should we decide to go that route.

> In any case, the outcome of installation should not depend on whether we
> do them in one or in several commands.

Agreed.

> Another idea: How about letting "guix package -u foo" upgrade only the
> package with name foo and the latest version if there are several with the
> same name?

That’s a possibility, yes.

But I wonder if there are other issues beyond -u.

Ludo’.

Re: Different versions of a package in the same profile?

[Andreas Enge]

On Sun, Nov 02, 2014 at 06:22:28PM +0100, Ludovic Courtès wrote:
> I don’t think so.  In this thread, I rather wanted to discuss the
> implications of allowing same-named packages to be installed in the same
> profile, should we decide to go that route.
> 
> > Another idea: How about letting "guix package -u foo" upgrade only the
> > package with name foo and the latest version if there are several with the
> > same name?
> That’s a possibility, yes.
> But I wonder if there are other issues beyond -u.

Good question, I do not know. But if we allow several packages with the same
name in a profile, I do not see another possibility for "guix package -u"
than my suggestion.

There is also the question of conflicts with identical file names. They are
already there now, but their probability should be higher with identical
package names. Maybe we need to rethink the handling of conflicts also.

Andreas

Re: Different versions of a package in the same profile?

[Federico Beffa]

Andreas Enge <andreas@enge.fr> writes:

> On Sun, Nov 02, 2014 at 06:22:28PM +0100, Ludovic Courtès wrote:
> There is also the question of conflicts with identical file names. They are
> already there now, but their probability should be higher with identical
> package names. Maybe we need to rethink the handling of conflicts also.

In the past I did use the packaging system called SEPP

http://oss.oetiker.ch/op-sepp/

It allow installing several versions of a program on a single system.
The way they use to avoid naming conflicts it to systematically add a
suffix to binary names, with the suffix corresponding to the version of
the package.  They even went one step further and they added a suffix
with the initials of the administrator who packaged the application.

Each program was available with several names. For program foo:
- foo
- foo-1.2.3
- foo-1.2.3-fb
Obviously if more foo versions were installed, only one would be
referred to by foo.  The others were available with versioned names.

As a user, the system did work very well.

To handle updating, specifying foo should update the version owning
the name foo.  To update another version one would give the versioned
name "foo-1.2.3".

Regards,
Fede

Re: Different versions of a package in the same profile?

[Ludovic Courtès]

Federico Beffa <beffa@ieee.org> skribis:

> Andreas Enge <andreas@enge.fr> writes:
>
>> On Sun, Nov 02, 2014 at 06:22:28PM +0100, Ludovic Courtès wrote:
>> There is also the question of conflicts with identical file names. They are
>> already there now, but their probability should be higher with identical
>> package names. Maybe we need to rethink the handling of conflicts also.
>
> In the past I did use the packaging system called SEPP
>
> http://oss.oetiker.ch/op-sepp/

Interesting.

> It allow installing several versions of a program on a single system.
> The way they use to avoid naming conflicts it to systematically add a
> suffix to binary names, with the suffix corresponding to the version of
> the package.  They even went one step further and they added a suffix
> with the initials of the administrator who packaged the application.
>
> Each program was available with several names. For program foo:
> - foo
> - foo-1.2.3
> - foo-1.2.3-fb
> Obviously if more foo versions were installed, only one would be
> referred to by foo.  The others were available with versioned names.
>
> As a user, the system did work very well.
>
> To handle updating, specifying foo should update the version owning
> the name foo.

OK, this is a strategy similar to what Andreas was suggesting.

> To update another version one would give the versioned name
> "foo-1.2.3".

I see.

Ludo’.