puck/lix
0
0
Fork 0
forked from lix-project/lix
Code Pull requests Activity

remove incomplete section: relocatability

Browse source
This commit is contained in:
Valentin Gagarin 2022-05-03 13:54:24 +02:00
parent 96876b1eae
commit 7cec9ee361
2 changed files with 0 additions and 16 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

1
doc/manual/src/SUMMARY.md.in
View file

@ -24,7 +24,6 @@
- [Derivations](architecture/store/drvs/drvs.md) - [Derivations](architecture/store/drvs/drvs.md)
- [Input-Addressing](architecture/store/drvs/ia.md) - [Input-Addressing](architecture/store/drvs/ia.md)
- [Content-Addressing (Experimental)](architecture/store/drvs/ca.md) - [Content-Addressing (Experimental)](architecture/store/drvs/ca.md)
- [Advanced Topic: Store object relocatability](architecture/store/relocatability.md)
- [Package Management](package-management/package-management.md) - [Package Management](package-management/package-management.md)
- [Basic Package Management](package-management/basic-package-mgmt.md) - [Basic Package Management](package-management/basic-package-mgmt.md)
- [Profiles](package-management/profiles.md) - [Profiles](package-management/profiles.md)

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

@ -1,15 +0,0 @@
## Advanced Topic: Store object relocation
Now that we know the fundamentals of the design of the Nix store, let's explore one consequence of that design: the question when it is permissible to relocate a store object to a store with a different mount point.
Recall from the section on [store paths](./store-paths.md) that concrete store paths look like `<store-dir>/<hash>-<name>`.
~~The two final restrictions of the previous section yield an alternative view of the same information.~~
Rather than associating store dirs with the references, we can say a store object itself has a store dir if and only if it has at least one reference.
This corresponds to the observation that a store object with references, i.e. with a store directory under this interpretation, is confined to stores sharing that same store directory, but a store object without any references, i.e. thus without a store directory, can exist in any store.
Lastly, this illustrates the purpose of tracking self references.
Store objects without self-references or other references are relocatable, while store paths with self-references aren't.
This is used to tell apart e.g. source code which can be stored anywhere, and pesky non-reloctable executables which assume they are installed to a certain path.
\[The default method of calculating references by scanning for store paths handles these two example cases surprisingly well.\]