Re: Using symlinks in 'local-file'

[ludo@gnu.org (Ludovic Courtès)]

Alex Kost <alezost@gmail.com> skribis:

> Ludovic Courtès (2015-06-15 23:44 +0300) wrote:
>
>> Alex Kost <alezost@gmail.com> skribis:
>>
>>> If one uses a relative symlink in 'local-file', it will lead to a broken
>>> symlink in the store as illustrated in the attached example.  So I think
>>> it either:
>>>
>>> - should be documented explicitly that 'local-file' adds a specified
>>>   file to the store blindly, which may lead to the problem with a broken
>>>   symlink.
>>>
>>> - or 'local-file' (or a deeper procedure) should take care of that case
>>>   and dereference a symlink if needed.
>>>
>>> WDYT?
>>
>> Actually, this only happens with #:recursive? #t, which is currently the
>> default.
>>
>> With #:recursive? #f, you get an error:
>>
>>
>> scheme@(guile-user)> ,enter-store-monad
>> store-monad@(guile-user) [1]> (gexp->derivation "foo" #~(symlink #$(local-file "/tmp/symlink1" #:recursive? #f) #$output))
>> guix/store.scm:604:22: In procedure add-to-store:
>> guix/store.scm:604:22: Throw to key `srfi-34' with args `(#<condition &nix-protocol-error [message: "regular file expected" status: 1] 30c5ab0>)'.
>>
>> So I think we should first make #:recursive? default to #f, since that’s
>> what we want by default, and optionally have the <local-file> gexp
>> expander resolve symlinks.
>>
>> WDYT?
>
> I agree, getting an error is better than a broken link, so I'm for
> making (#:recursive? #f) a default.  And resolving symlinks would
> probably be even better.

Done in commits 020f3e4 and 7833db1.

>>> (define (call-derivation drv)
>>>   (apply system*
>>>          (cons (derivation-builder drv)
>>>                (derivation-builder-arguments drv))))
>>
>> This is quite original.  ;-)
>
> I suppose that's a polite version of "That's not how it should be done".

Well, yes and no; I find it clever actually.

> I just don't know what the proper way to "call" derivation is :-)

With ‘build-derivations’, which lets guix-daemon built it on your behalf
in a container.

Roughly, what the daemon does is:

   (eval-in-container
     #~(apply system*
              (cons (derivation-builder drv)
                    (derivation-builder-arguments drv))))

in terms of David’s forthcoming ‘eval-in-container’.  ;-)

Ludo’.