Re: Problems with downloading from https

[Ludovic Courtès]

Mark H Weaver <address@hidden> skribis:

> address@hidden (Ludovic Courtès) writes:
>
>> Alex Kost <address@hidden> skribis:
>>
>>> Ludovic Courtès (2014-10-26 16:46 +0300) wrote:
>>>
>>>> Alex Kost <address@hidden> 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’.