Re: Package inputs in manifests

[Bengt Richter <bokr@bokr.com>]

Hi Timothy,

On +2019-11-24 02:17:20 -0500, Timothy Sample wrote:
> Hi Bengt,
> 
> Bengt Richter <bokr@bokr.com> writes:
> 
[...]
> > ┌─────────────────────────────────────────────────────────────────────────────────────┐
> > │ 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>.
                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
			 a really good read, glad you added your "aside"
> 
> Hope that helps!

Very much so!

My mistaken assumption was that the current guix was an implementation
of an "intensional" model whose implementation I just wasn't understanding ;-p

Crystal lear now, thanks :) Preconceptions die hard ;-/
 
> 
> [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.

I found that explored and explained in the thesis too.

I hope there's an incrementally growing index of guix reference docs
like that, with urls and synopses in the citations.

Your post here (before I cluttered it up :) could be a model entry.
> 
> 
> -- Tim

Thanks again.
-- 
Regards,
Bengt Richter