a2fed6db9e
* manual: Contributing -> Development, Hacking -> Building what's currently called "hacking" are really instructions for setting up a development environment and compiling from source. we have a contribution guide in the repo (which rightly focuses on GitHub workflows), and the material in the manual is more about working on the code itself. since we'd otherwise have three headings that amount to "Building Nix", this change also moves the "classic Nix" instructions to the top. we may want to reorganise this in the future, and bring contributor-oriented information closer to the code, but for now let's stick to more accurate names to ease navigation.
4.3 KiB
Content-Addressing Store Objects
Just like File System Objects, Store Objects can also be content-addressed, unless they are input-addressed.
For store objects, the content address we produce will take the form of a Store Path rather than regular hash. In particular, the content-addressing scheme will ensure that the digest of the store path is solely computed from the
- file system object graph (the root one and its children, if it has any)
- references
- store directory
- name
of the store object, and not any other information, which would not be an intrinsic property of that store object.
For the full specification of the algorithms involved, see the specification of store path digests.
Content addressing each part of a store object
File System Objects
With all currently supported store object content addressing methods, the file system object is always content-addressed first, and then that hash is incorporated into content address computation for the store object.
References
With all currently supported store object content addressing methods, other objects are referred to by their regular (string-encoded-) store paths.
Self-references however cannot be referred to by their path, because we are in the midst of describing how to compute that path!
The alternative would require finding as hash function fixed point, i.e. the solution to an equation in the form
digest = hash(..... || digest || ....)which is computationally infeasible. As far as we know, this is equivalent to finding a hash collision.
Instead we just have a "has self reference" boolean, which will end up affecting the digest.
Name and Store Directory
These two items affect the digest in a way that is standard for store path digest computations and not specific to content-addressing. Consult the specification of store path digests for further details.
Content addressing Methods
For historical reasons, we don't support all features in all combinations. Each currently supported method of content addressing chooses a single method of file system object hashing, and may offer some restrictions on references. The names and store directories are unrestricted however.
Flat
This uses the corresponding Flat method of file system object content addressing.
References are not supported: store objects with flat hashing and references can not be created.
Text
This also uses the corresponding Flat method of file system object content addressing.
References to other store objects are supported, but self references are not.
This is the only store-object content-addressing method that is not named identically with a corresponding file system object method. It is somewhat obscure, mainly used for "drv files" (derivations serialized as store objects in their "ATerm" file format). Prefer another method if possible.
Nix Archive
This uses the corresponding Nix Archive method of file system object content addressing.
References (to other store objects and self references alike) are supported so long as the hash algorithm is SHA-256, but not (neither kind) otherwise.
Git
Warning
This method is part of the
git-hashingexperimental feature.
This uses the corresponding Git method of file system object content addressing.
References are not supported.
Only SHA-1 is supported at this time. If SHA-256-based Git becomes more widespread, this restriction will be revisited.