agreed points:

  • docker image, vagrant box, etc. are all just “packages”

  • which container/VM does not matter for reproducibility
  • it does matter for ease of use/setup

  • perfect buildinfo is the goal
  • intermediate steps can be useful

notes:

  • bazel, build only from directly available sources, no net, into docker
  • fdroid, vagrant to build up on VirtualBox
  • mozilla/nix, build up images per task, never use a base image

  • docker, AWS image, VirtualBox

  • basel builds up debian/ubuntu docker images
  • all source code, local and upstream, are checked into local source repo
  • 5 base images, security and legal reviewed

  • nix could do base images, but don’t see the need yet.
  • could be used for caching to speed things up

  • with certain compilers (e.g. javac), wide variations can produce the same thing
  • can’t be a buildinfo dependency, too hard to deal with problems

  • tools for specifying buildinfo
  • blaze forces central build infrastructure, so forces standard build envs
  • nix is a build tool first, and incidentally a package manager

  • Debian images can be reproducible using snapshots, specify date to snapshots in /etc/apt/sources.list

  • it is possible to not require full buildinfo in advance, if there is a reproducible base image that builds against user input, and it reproduces any given user submitted build, then that can also generate the buildinfo

what are the benefits of bit-perfect reproducible

  • more effective caching
  • security audits, easy to track binaries to find original source
  • catching bugs by finding unexpected changes

-