NixOS identifiers merge uniqueness/descriptive identification
NixOS is an operating system with its own "functional" nixpkg
packaging system here:
http://
The identification scheme used in NixOS can be seen here:
http://
with an identifier that looks like
/nix/
The identifier is composed of two pieces
1) a unique (and fixed length) hash string encoded in base32
2) a human readable (and variable length) name-version component
What is elegant is that the machine-readable portion is fixed length
(and shorter than hex because of base32 encoding) while the human readable
portion is useful for ad hoc pattern matching and human debugging tasks.
A similar hybrid scheme combining a unique machine readable identifier
with (what is typically used in RPM) the usual {N,E,V,R,A} tuple satisfies
both the need for uniqueness as well as the need for readability quite well.
A similar scheme for *.rpm packages should be attempted conventionally
to avoid the confusions that result from using just NEVRA as an identifier.
E.g. a package that is simply rebuilt WILL have some changes: the confusions
occur because of the importance of the changes, where timestamps may
or may not matter in some specific context. There are also more profound
changes that can occur when a package is rebuilt on a differently configured
build system which a base32 unique id would help disambiguate.
Blueprint information
- Status:
- Started
- Approver:
- Jeff Johnson
- Priority:
- Low
- Drafter:
- Jeff Johnson
- Direction:
- Approved
- Assignee:
- Jeff Johnson
- Definition:
- Discussion
- Series goal:
- None
- Implementation:
-
Slow progress
- Milestone target:
- None
- Started by
- Jeff Johnson
- Completed by
Related branches
Related bugs
Sprints
Whiteboard
A large number of NixOS tools have been incorporated @rpm5.org
already (from nixos-0.15). The tools are largely rewrites of various
Nix tools rewritten in C instead of perl/shell/
Having "drop-in" replacements for Nix tools helped with QA by mix-n-match
replacement within NixOS checking for identically functional.
The work was promising/useful enough that an embedding of NixOS in RPM
has been started, the goal being interoperability of RPM <-> NixOS package
management. There are many sound engineering ideas in NixOS and a
"functional" approach to package management that would benefit RPM.
Work Items
Dependency tree
* Blueprints in grey have been implemented.
