max/nix-super
1
0
Fork 0
mirror of https://github.com/privatevoid-net/nix-super.git synced 2024-11-10 00:08:07 +02:00
Code Issues Projects Releases Packages Wiki Activity Actions

move closure property to discussion references

Browse source
This commit is contained in:
Valentin Gagarin 2022-05-26 05:15:53 +02:00
parent 445f753a82
commit 4341849193
2 changed files with 17 additions and 21 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

15
doc/manual/src/architecture/store/objects.md
View file

@ -35,21 +35,6 @@ A bare file or symlink can be a root file system object.
Symlinks pointing outside of their own root, or to a store object without a matching reference, are allowed, but might not function as intended.
## Reference {#reference}
A store object can reference other store objects.
Nix stores have the *closure property*: for each store object in the store, all the store objects it references must also be in the store.
Building, copying and deleting store objects must be done in a way that obeys this property:
- Build results must only refer to store objects in the closure of the build inputs.
- Store objects being copied must refer to objects already in the destination store.
Recursive copying must either proceed in dependency order or be atomic.
- We can only safely delete unreferenced objects.
### Reference scanning
While references could be arbitrary paths, Nix requires them to be store paths to ensure correctness.

23
doc/manual/src/architecture/store/store.md
View file

@ -52,15 +52,26 @@ References are [opaque][opaque-data-type], [unique identifiers][unique-identifie
The only way to obtain references is by adding or building store objects.
A reference will always point to exactly one store object.
An added store object cannot have references, unless it is a build task.
Nix stores have the *closure property*: for each store object in the store, all the store objects it references must also be in the store.
Building a store object will add appropriate references, according to provided build instructions.
These references can only come from declared build inputs, and are not known to build instructions a priori.
Adding, building, copying and deleting store objects must be done in a way that obeys this property:
A store object cannot be deleted as long as it is reachable from a reference still in use.
Garbage collection will delete all store objects that cannot be reached from any reference in use.
- A newly added store object cannot have references, unless it is a build task.
<!-- more details in section on garbage collection, link to it once it exists -->
- Build results must only refer to store objects in the closure of the build inputs.
Building a store object will add appropriate references, according to provided build instructions.
These references can only come from declared build inputs.
- Store objects being copied must refer to objects already in the destination store.
Recursive copying must either proceed in dependency order or be atomic.
- We can only safely delete store objects which are not reachable from any reference still in use.
Garbage collection will delete all store objects that cannot be reached from any reference in use.
<!-- more details in section on garbage collection, link to it once it exists -->
[garbage-collection]: https://en.m.wikipedia.org/wiki/Garbage_collection_(computer_science)
[immutable-object]: https://en.m.wikipedia.org/wiki/Immutable_object