nixos/rfcs
1
0
Fork 0
mirror of https://github.com/NixOS/rfcs.git synced 2025-11-09 12:06:11 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions

17: explain metadata alternatives

Browse source
This commit is contained in:
Wout Mertens 2020-11-09 07:42:59 +01:00
parent b0362a0a43
commit b0b655ed1e
1 changed files with 13 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

13
rfcs/0017-intensional-store.md
View file

@ -376,3 +376,16 @@ There are a few choices made in this RFC, here we describe alternatives and why
Since the names are always different, the `$cas` entries and `$cas.m` files could stay in `/nix/store`. The benefit would be that NixPkgs doesn't have to be audited for hardcoded `/nix` paths.
However, this keeps the problem of some installations not having permission to create a `/nix` directory, and makes it much harder to share the store between hosts (as long as non-`$cas` entries are present).
### No metadata
Not keeping metadata in the Store means that the Store by itself doesn't have enough information to do garbage collection, nor to let a system boot from a given `$cas`
### Keep metadata in directory with Store entry
Since the Store entries can be files or directories, that means that files would have to be put in a directory, for example `$cas` becomes `$cas/_`.
Then directory entries would have to do the same for symmetry. This requires many code changes and requires extra storage, even if an entry doesn't have any runtime dependencies.
### Add name to metadata
The name and version are subjective data. Adding it to metadata would cause `$cas` to change and increases storage. The only consumer of this data is the end user, who should also have the data available in their Trust DB.