Ludovic Courtès (2014-10-27 15:24 +0300) wrote: > Mark H Weaver <m...@netris.org> skribis: > >> l...@gnu.org (Ludovic Courtès) writes: >> >>> Alex Kost <alez...@gmail.com> skribis: >>> >>>> Ludovic Courtès (2014-10-26 16:46 +0300) wrote: >>>> >>>>> Alex Kost <alez...@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
