Support package pinning/downgrade

[gdm85]

As discussed in #53 and https://github.com/bitcoin/bitcoin/issues/4265 I propose a (very low priority) feature request to support aside from the sha256sum of installed .deb packages a second list in a text file with one package per line, in format:

package-xyz=0.1.0
package-abc=0.3.0

Given that an Ubuntu image is always used to build, we could afterwards restore older version of packages by setting proper apt sources (archives.ubuntu.com) and the issuing:

apt-get install $(<such-list.txt)

This helps at increasing determinism/reproducibility in case the distro is changed upstream, although falls short in case package versions go completely missing upstream even from archives.

NOTE: downgrade is basically not supported by any package mantainer, thus it would be best to completely circumvent the problem of changed packages by using only an officially released Ubuntu ISO (and never issuing an apt-get update) and a set pool of necessary .deb package dependencies put directly in the apt-cacher-ng cache. Each project could then host their own APT archives source to support the reproducible build.

[josephbisch]

This is an interesting idea. The problem is that debootstrap (and consequentially vmbuilder, because it uses debootstrap under the hood) installs the newest point release by default. It may be possible for this to work if it is possible to disable the updates repository. Debian has snapshot.debian.org, which makes it easy to get a repository that reflects a particular point in time. It is possible to get old versions of packages for Ubuntu too, but there isn't an automated repository service like snapshot.debian.org for Ubuntu.

So if Debian VM images were supported, it would be a little easier, in the sense that you wouldn't need to setup a repository yourself.

[kleetus]

My suggestion for this issue would be:

1. (IMHO) I would not try and downgrade Trusty's packages used for build dependencies. There is, most likely, a very good reason the maintainers bumped the version.
2. Instead, gitian builders should build using whatever inputs (dependencies) they get, at the time, from the target VM (Trusty in this case) and produce their assert files.
3. Gitian builders should only compare their final results given their collection of inputs. This isn't usually a big issue because, prior to a release, gitian builds are done roughly at the same time.
4. Then maybe Travis can watch for changes in the target VM's packages and perform a gitian build on demand for future builders to compare against. Granted, later gitian builders won't be able to reproduce the same final hashes as what was released, but they can see why the was a change given same starting source code. Parties that originally did a gitian build at release time can also reproduce their builds very easily to help out newcomers.

[devrandom]

I think package snapshots are good for two reasons:

• so that a post-mortem can be done if there's a problem
• to replicate a build

Perhaps it would make sense to make our own partial snapshots as part of the build process.