[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Package inputs in manifests
From: |
Bengt Richter |
Subject: |
Re: Package inputs in manifests |
Date: |
Sun, 24 Nov 2019 19:42:47 -0800 |
User-agent: |
Mutt/1.12.2 (2019-09-21) |
Hi Timothy,
On +2019-11-24 02:17:20 -0500, Timothy Sample wrote:
> Hi Bengt,
>
> Bengt Richter <address@hidden> 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
- Re: Profiles/manifests-related command line interface enhancements, (continued)
Re: Profiles/manifests-related command line interface enhancements, Ludovic Courtès, 2019/11/06
- Re: Profiles/manifests-related command line interface enhancements, zimoun, 2019/11/07
- Package inputs in manifests, Ludovic Courtès, 2019/11/17
- Re: Package inputs in manifests, Bengt Richter, 2019/11/17
- Re: Package inputs in manifests, zimoun, 2019/11/18
- Re: Package inputs in manifests, Ludovic Courtès, 2019/11/23
- Re: Package inputs in manifests, Bengt Richter, 2019/11/24
- Re: Package inputs in manifests, Timothy Sample, 2019/11/24
- Re: Package inputs in manifests,
Bengt Richter <=
Re: Package inputs in manifests, zimoun, 2019/11/18