Re: inputs vs. native-inputs vs. propagated-inputs

[Ludovic Courtès]

Lukas Gradl <address@hidden> skribis:

> address@hidden (Ludovic Courtès) writes:
>
>> Leo Famulari <address@hidden> skribis:
>>
>>> I _think_ that `gc --references` works by querying the database for a
>>> list of references in the store item you give it as an argument. I think
>>> that the information in the database is created after building, by
>>> scanning the files of the package's output in /gnu/store, looking for
>>> strings that appear to be paths in /gnu/store. I say "I think" because I
>>> am not sure. I don't understand that part of the code very well yet.
>>
>> That’s 100% correct!  :-)  Namely, ‘guix gc --references’ makes an RPC to
>> the daemon, which then looks things up in the database (see the ‘Refs’
>> table in nix/libstore/schema.sql.)
>>
>> Scanning for references indeed happens at the end of a successful build,
>> in ‘scanForReferences’ in libstore/references.cc.  Since scanning is
>> expensive (I/O-intensive), the result is stored in the database.
>
> Sorry, this might be a dumb question, I don't quite understand the
> concept of these references.  Why are references important?  Shouldn't
> every store item know which other store-items are related to it from the
> "inputs"-field in its definition?  Why is it necessary to keep track of
> the references?

The “references” of a store item are its run-time dependencies, a subset
of the ‘inputs’ etc. fields, which are themselves the compile-time
dependencies.

If those run-time dependencies were not inferred automatically by the
daemon, we’d have to maintain them individually, and this would be
error-prone and imprecise.

Run-time dependency information is what allows Guix to know which
substitutes need to be downloaded when installing from substitutes, and
it’s what allows the garbage collector to determine which store items
are “live”, and which ones are not.

HTH!

Ludo’.