Re: Problems with downloading from https

[Alex Kost]

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

> 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?

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