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
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.