Re: Package inputs in manifests

[Timothy Sample]

Hi Bengt,

Bengt Richter <address@hidden> writes:

> On +2019-11-23 15:05:49 +0100, Ludovic Courtès wrote:
>> 
>> Bengt Richter <address@hidden> skribis:
>> 
>> > Can "collisions" be collisions even if the targets are bit-identical?
>> 
>> Collisions are when the same package appears several times with
>> different version strings, or when the same package/version appears
>> several times with a different store item.
>
> In this case, the "Inode: 1966255" entries below say the gzips are not
> different store items,
> so what am I missing about "version strings?" :)
>
> Why would there be different prefixes? Are transient-state link counts somehow
> entering into prefix hash calculations? But that's directory state, isn't it? 
> ...
>
> ┌─────────────────────────────────────────────────────────────────────────────────────┐
> │ So again, what exactly goes into computing those /gnu/store/.../file 
> prefixes?? ;-) │
> └─────────────────────────────────────────────────────────────────────────────────────┘

A store prefix is the hash of all the inputs used to build a store item.
It has nothing to do with the contents of the output [1].  Two store
items may have identical contents but different prefixes.

Say we have a package A.  If we build A we might get a file called
“/gnu/store/abc123-a” with contents “this is a”.  Now imagine that we
make a change to A that doesn’t change its output.  If we build this
changed package A′, we would get a file called “/gnu/store/xyz456-a”
(note the different prefix) but its contents would still be “this is a”.

What’s more is that Guix will notice that these two files are the same
and deduplicate them through hard linking.  From the manual:

    By default, files added to the store are automatically
    “deduplicated”: if a newly added file is identical to another one
    found in the store, the daemon makes the new file a hard link to the
    other file.

This explains why you have only one inode.

As an aside, this is called the “extensional” model of functional
package management.  There is also an “intensional” model where the
prefixes are hashes of the content (i.e., everything in the store is
content addressable).  It has some neat properties, but also some
complications.  This is all discussed in Eelco Dolstra’s Ph.D. thesis
which introduces Nix: <https://nixos.org/~eelco/pubs/phd-thesis.pdf>.

Hope that helps!

[1] There are “fixed-output” derivations where the prefix is the hash of
the contents.  They are used for things like a source archive, where you
don’t care how you get it, as long as you have the right one.


-- Tim