Page MenuHomeSerpent OS

Conary-inspired example with readable source and binary file hashes for source and build-artifacts
ActivePublic

Authored by ermo on Apr 10 2021, 5:35 PM.
Would it make sense to have a stone.yml and then also have tool-maintained (hard)link to it that has an autogenerated unique name corresponding to its tag? FWIW, this assumes one git repo per-package (which may or may not be smart).
Example:
The (...)/nano/stone.yml file only contains a version string (no other revision/commit/etc. info) and has a commit (tag) history via git.
The machine-generated unique name then follows the pattern %(name)-%(version)-%(svnlike-commitrev)-%(sourcerev)-%(buildrev).yml pattern with the following cases:
Starting "hash" or "state": nano-5.5-187-42-1.yml -> stone.yml
1./ The common revdep-rebuild case [= no git diff source changes]:
%(name) is unchanged (nano)
%(version) is unchanged ("5.5")
%(svnlike-commitrev) is bumped by 1 (187 -> 188)
%(sourcerev) is kept at its current value (42)
%(buildrev) is bumped by 1 (1 -> 2) because %(svnlike-commitrev) changed and %(sourcerev) didn't.
New State: nano-5.5-188-42-2.yml -> stone.yml
2./ Add a patch without changing %(version) [= git diff source changes]:
%(name) is unchanged (nano)
%(version) is unchanged ("5.5")
%(svnlike-commitrev) is bumped by 1 (188 -> 189)
%(sourcerev) is bumped by 1 (42 -> 43)
%(buildrev) is reset to 1 because %(sourcerev) changed (2 -> 1)
New State: nano-5.5-189-43-1.yml -> stone.yml
3./ Change %(version) [= git diff source changes]
%(name) is unchanged (nano)
%(version is changed ("5.4")
%(svnlike-commitrev) is bumped by 1 (189 -> 190)
%(sourcerev) is bumped by 1 (43 -> 44)
%(buildrev) is reset to 1 because %(sourcerev) changed (1 -> 1)
New State: nano-5.4-190-44-1.yml -> stone.yml
In all of this, the "hash" uniquely describes the state of the nano stone.yml, such that
a git tag can be used to maintain the hardlink "hash" filename that points to the current
version of stone.yml.
In the same vein, binary builds could be "annotated" with a "hash" of their subscriptions, such that a .yml is mapped to a set of ( one to many relations to) binaries via the git tag and a set of hashes corresponding to subscriptions?
foreach (s; Subscriptions) {
check if a cache asset matching the git-tag+subscription-hash exists;
if !exists; build it locally (depending on the configured policy) XOR error out
else; serve it
}
Populated example with files:
/moss/cache/x86_64/n/nano/: (<- arbitrarily chosen path)
nano_5.4_190_44_1.yml -> stone.yml
nano_5.4_190_44_1_[x86_64,glibc,haswell,AVX512].stone
nano_5.4_190_44_1_[x86_64,glibc,haswell,!AVX512].stone
nano_5.4_190_44_1_[x86_64,glibc,bdver2,local].stone
nano_(5.5_188_42_2)_to_(5.4-190_44_1)[x86_64,glibc,haswell,AVX512].stone.delta
nano_(5.5_188_42_2)_to_(5.4-190_44_1)[x86_64,glibc,haswell,!AVX512].stone.delta
nano_(5.5_189_43_1)_to_(5.4-190_44_1)[x86_64,glibc,haswell,AVX512].stone.delta
nano_(5.5_189_43_1)_to_(5.4-190_44_1)[x86_64,glibc,haswell,!AVX512].stone.delta
stone.yml