Some newbie questions

Some newbie questions

[Jan Synáček]

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

Hello,

I've been playing with guix a bit and I must say I really like it. I don't
understand a few things though.

1) How do I tell if a package I have installed had been built locally or
downloaded as a substitute?

2) There are a lot of packages with executable binaries in the bin/
subfolder in /gnu/store. However, if I didn't explicitly install the
package, I don't have it in my profile and can't easily reach the binary
without first looking it up in the store. Do I have to always "install" a
package to be able to use run it easily?

Please, excuse my not-so-clear questions, I still don't fully understand
how things really work in guix.

Cheers,
-- 
Jan Synáček

[-- Attachment #2: Type: text/html, Size: 953 bytes --]

Re: Some newbie questions

[Thompson, David]

On Thu, Oct 29, 2015 at 6:08 AM, Jan Synáček <jan.synacek@gmail.com> wrote:
> Hello,
>
> I've been playing with guix a bit and I must say I really like it. I don't
> understand a few things though.
>
> 1) How do I tell if a package I have installed had been built locally or
> downloaded as a substitute?

You don't.  You can think of substitution is an optimization
technique, the results are indistinguishable except for that it likely
took less time to get the substitute.  It's possible to query the
substitute server to see if it has the store item that you have, but
that doesn't mean that your copy was retrieved from there necessarily.
Other than that, the Guix tools will tell you at build/download time
whether or not it is building from source or downloading a pre-built
binary.  What use-case do you have in mind?

> 2) There are a lot of packages with executable binaries in the bin/
> subfolder in /gnu/store. However, if I didn't explicitly install the
> package, I don't have it in my profile and can't easily reach the binary
> without first looking it up in the store. Do I have to always "install" a
> package to be able to use run it easily?

Not always, but usually that is what you'd do.  This is how we achieve
isolation of environments.  Different users, or the same user in
different circumstances, will want different sets of programs and
libraries available to them.

That said, if you just want to do a one-off run of something, you can
use 'guix environment' instead, which will not install anything to
your user profile, like so:

    guix environment --ad-hoc wget -- wget http://gnu.org/s/guix

> Please, excuse my not-so-clear questions, I still don't fully understand how
> things really work in guix.

No problem at all.  Welcome!

- Dave

Re: Some newbie questions

[Jan Synáček]

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

On Thu, Oct 29, 2015 at 2:23 PM, Thompson, David <dthompson2@worcester.edu>
wrote:

> On Thu, Oct 29, 2015 at 6:08 AM, Jan Synáček <jan.synacek@gmail.com>
> wrote:
> > Hello,
> >
> > I've been playing with guix a bit and I must say I really like it. I
> don't
> > understand a few things though.
> >
> > 1) How do I tell if a package I have installed had been built locally or
> > downloaded as a substitute?
>
> You don't.  You can think of substitution is an optimization
> technique, the results are indistinguishable except for that it likely
> took less time to get the substitute.  It's possible to query the
> substitute server to see if it has the store item that you have, but
> that doesn't mean that your copy was retrieved from there necessarily.
> Other than that, the Guix tools will tell you at build/download time
> whether or not it is building from source or downloading a pre-built
> binary.  What use-case do you have in mind?


Nothing really specific. I was just curious if it was possible. Now that I
think about it,
I should get the same result whether building myself or installing a
substitute,
right?


> > 2) There are a lot of packages with executable binaries in the bin/
> > subfolder in /gnu/store. However, if I didn't explicitly install the
> > package, I don't have it in my profile and can't easily reach the binary
> > without first looking it up in the store. Do I have to always "install" a
> > package to be able to use run it easily?
>
> Not always, but usually that is what you'd do.  This is how we achieve
> isolation of environments.  Different users, or the same user in
> different circumstances, will want different sets of programs and
> libraries available to them.
>
> That said, if you just want to do a one-off run of something, you can
> use 'guix environment' instead, which will not install anything to
> your user profile, like so:
>
>     guix environment --ad-hoc wget -- wget http://gnu.org/s/guix
>
> > Please, excuse my not-so-clear questions, I still don't fully understand
> how
> > things really work in guix.
>
> No problem at all.  Welcome!
>
> - Dave
>

Thank you!

I'm curious about one more thing. In /gnu/store/, there are built packages,
which I understand.
Then there are derivations, -builder files, standalone statically linked
binaries, some patches
and also some scheme files. There's also the .links directory that contains
various file formats
as well, only this time their names are only hashes. Does any
documentation/source
of information about what all those are exist? I couldn't find anything.
The .links directory takes
over 2GiB on my machine and I wonder why.

Cheers,
-- 
Jan Synáček

[-- Attachment #2: Type: text/html, Size: 3927 bytes --]

Re: Some newbie questions

[Ludovic Courtès]

"Thompson, David" <dthompson2@worcester.edu> skribis:

> On Thu, Oct 29, 2015 at 6:08 AM, Jan Synáček <jan.synacek@gmail.com> wrote:
>> Hello,
>>
>> I've been playing with guix a bit and I must say I really like it. I don't
>> understand a few things though.
>>
>> 1) How do I tell if a package I have installed had been built locally or
>> downloaded as a substitute?
>
> You don't.

There’s a trick that ‘guix challenge’ uses to determine whether
something was locally built or substituted: run ‘guix build --log-file
whatever’ and see whether that returns a local build log or not.

This is a fairly reliable way to get that information.  There can be
false-negatives if you remove logs.  There cannot be false positives,
AFAICS, since even ‘guix archive --import’ of something already present
does not actually overwrite it.

It cannot tell the difference between really locally-built and offloaded
builds, though.

Ludo’.

Re: Some newbie questions

[Adam Pribyl]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1910 bytes --]

On Thu, 29 Oct 2015, Jan Synáček wrote:

> On Thu, Oct 29, 2015 at 2:23 PM, Thompson, David <dthompson2@worcester.edu>
> wrote:
>
>> On Thu, Oct 29, 2015 at 6:08 AM, Jan Synáček <jan.synacek@gmail.com>
>> wrote:
>>> Hello,
>>>
>>> I've been playing with guix a bit and I must say I really like it. I
>> don't
>>> understand a few things though.
>>>
>>> 1) How do I tell if a package I have installed had been built locally or
>>> downloaded as a substitute?
>>
>> You don't.  You can think of substitution is an optimization
>> technique, the results are indistinguishable except for that it likely
>> took less time to get the substitute.  It's possible to query the
>> substitute server to see if it has the store item that you have, but
>> that doesn't mean that your copy was retrieved from there necessarily.
>> Other than that, the Guix tools will tell you at build/download time
>> whether or not it is building from source or downloading a pre-built
>> binary.  What use-case do you have in mind?
>
>
> Nothing really specific. I was just curious if it was possible. Now that I
> think about it,
> I should get the same result whether building myself or installing a
> substitute,
> right?


Right. Thats what is going on here - binary same.


> I'm curious about one more thing. In /gnu/store/, there are built packages,
> which I understand.
> Then there are derivations, -builder files, standalone statically linked
> binaries, some patches
> and also some scheme files. There's also the .links directory that contains
> various file formats
> as well, only this time their names are only hashes. Does any
> documentation/source
> of information about what all those are exist? I couldn't find anything.
> The .links directory takes
> over 2GiB on my machine and I wonder why.


No idea. :)


> Cheers,
> -- 
> Jan Synáček


Adam Pribyl

Re: Some newbie questions

[Andreas Enge]

On Thu, Oct 29, 2015 at 10:11:11PM +0100, Adam Pribyl wrote:
> >Nothing really specific. I was just curious if it was possible. Now that I
> >think about it,
> >I should get the same result whether building myself or installing a
> >substitute,
> >right?
> Right. Thats what is going on here - binary same.

Well, that is assuming that the builds are deterministic - which is our goal,
but which is not guaranteed. If a binary encodes the build time, for example,
then different builds will yield different results.

> >The .links directory takes
> >over 2GiB on my machine and I wonder why.

If I remember correctly, these are just hard links into the store that serve
for deduplication. So the storage space used there does not matter, it just
counts files that are already in the store a second time.

Andreas

Re: Some newbie questions

[Ludovic Courtès]

Andreas Enge <andreas@enge.fr> skribis:

> On Thu, Oct 29, 2015 at 10:11:11PM +0100, Adam Pribyl wrote:
>> >Nothing really specific. I was just curious if it was possible. Now that I
>> >think about it,
>> >I should get the same result whether building myself or installing a
>> >substitute,
>> >right?
>> Right. Thats what is going on here - binary same.
>
> Well, that is assuming that the builds are deterministic - which is our goal,
> but which is not guaranteed. If a binary encodes the build time, for example,
> then different builds will yield different results.

But you can help!  :-)

  https://lists.gnu.org/archive/html/guix-devel/2015-10/msg00696.html

>> >The .links directory takes
>> >over 2GiB on my machine and I wonder why.
>
> If I remember correctly, these are just hard links into the store that serve
> for deduplication.

Yes, see also:

  https://lists.gnu.org/archive/html/guix-devel/2014-09/msg00422.html

Ludo’.