A system running with the isthmus package manager keeps track of packages as recipes in text files, corresponding binary builds are kept track of in
isthmus-i486/log
Where each line is of the form:
package-name ver 18sha256ofrecipie 9sha256ofbinary 88sha256oftarball
After each successful package generation a new entry is added, thus the last known binary for the current recipe is what we'd want installed. Or one created if that doesn't exist. We might also know about binaries corresponding to recipe hashes with downloaded logs.
Most of isthmus is implemented in the filesystem, the shell script eid is a result of these data storage decisions.
Since recipes and packages are stored by the hash of their contents, they are suited for storage or distribution in IPFS or similar systems - in service of such goals, isthmus strives towards having reproducible builds.
Important paths for isthmus:
eid - the shell script doing all of isthmus' logic
arch/ - symlink to a file in recipes/ for current architecture
sources/ - downloaded source tarballs, as referenced in recipes
bits/ - patches and files needed to build various recipes
local/ - local recipes (or from git when the core repo is cloned)
recipes/ - collated set of recipes
i488/isthmus/recipes - the copy of the collated set of recipes for i486 architecture work dir
isthmus-i486/ - binary package files for i486
isthmus-i486/log - log of builds, contains an index matching recipes +
tarball hash = binary package hash, last entry
matching a set of sources is considered to be the last
valid build.
i488/ - work root folder for i486
i488/isthmus/ - isthmus folder for i486 system
i488/isthmus/installed - recipes which are installed, flat file hierarchy
i488/isthmus/file_listings - the files contained in installed packages, for uninstall
i488/isthmus/isthmus-i486 - binary packages available to system - synced with same folder at top-level.
repos - a text file containing upstream recipe/binary repos one per line
remote/ - meta data from remote repos
remote/c9cef6e.../ - a remote
remote/c9cef6e.../url - the url of the remote folder (folder name is hash of url)
The remote folders contain manually synced files and their checksums, eid uses the checksums to avoid refetching unncessesarily.
remote/c9cef6e.../recipes.tar.gz.sha256
remote/c9cef6e.../recipes.tar.gz
remote/c9cef6e.../recipes/
remote/c9cef6e.../bits.tar.gz.sha256
remote/c9cef6e.../bits.tar.gz
remote/c9cef6e.../bits/
remote/c9cef6e.../isthmus-i486/log.sha256
remote/c9cef6e.../isthmus-i486/log
The eid script works with the above in file-system data structure, either in master mode, when all other things are in subdirectories of the top-level isthmus folder. (and the eid script, or a symlink to it, lives in this folder). Or in a system mode, where the eid script is in /usr/bin/eid and the isthmus folder is /isthmus , which is also made the current working directory -- making full but relative (without / prefix) a universally working way of addressing files.
The resolve order for validity is remote binary builds corresponding to recipe hashes overriding local ones, the idea being that if one is adding a new recipe - it won't exist on remote anyways - and having the remote canonical package take over - that is built from empty deps only file system take over from the local version.