nix and guix have the right idea, but you have to learn an unfamiliar
programming language to interact with the system. both just use this
to write a config parser for their special build system.
speaking to dtluna earlier, i brought up some package formats including
PKGBUILD and pkgsrc. after some discussion we concluded that a
declarative package format is preferable to executing special shell
scripts. we'd like to avoid having a turing complete language in here.
an example package definition:
https://source.heropunch.io/tomo/yeet/src/branch/master/pkgbuild.toml
external scripts might be needed in some cases, but many of these could
be standardized and built into the system. these can just shell out to
the build environment.
in order to make the build source transparent we need to keep track of
our inputs. nix includes the hash of the package definition and the
name of the package.
/store
m0ghbai02cd8...-glibc-2.3.4
lib
libc.so.6
8yzprq56x5fa...-gtk+-2.6.6
lib
libgtk-x11-2.0.so.0
mkmpxqr8d7f7...-firefox-1.0
bin
firefox
https://web.archive.org/web/20190421081840/https://nixos.org/~eelco/pubs/secsharing-ase2005-final.pdf
each of these build prefixes can be used as a "layer" in another build
that produces matching inputs. nix uses symlinks, but a virtual
filesystem is going to be a lot more flexible i think.
a multihash format might be a good thing to use here too. i would also
like to spend some time on reproducible builds so that we can mirror
the artifacts over bit torrent.
https://wiki.debian.org/ReproducibleBuilds
thoughts?
