3 ms·
I will say that it's _extremely easy_ to just list `Dockerfile` in your output dependencies if it matters enough for you to care. Stuff from apt/etc as well? p
by rtpg 2y ago
I will say that it's _extremely easy_ to just list `Dockerfile` in your output dependencies if it matters enough for you to care.
Stuff from apt/etc as well? put the install script in the dependencies.
Really care about the version numbers? Add a test that just calls `tool -v` and compares the output to some fixed number. Add a big comment.
Is it perfect? No! Is it hermetic! Hell no! But is it going to catch a hell of a lot of stuff and get you fast tests along the way? Yes!
The biggest point with all CI/CD is to get as much value as you can from these systems, while introducing the least amount of friction. And velocity gained from these systems mean that if you find an issue, you can fix it quickly. It's an amazing feedback loop, and leaning into that feedback loop is way more valuable than writing `gettext` compilation scripts.
- zelphirkalt 2y agoBut what does installing things via apt have to do with reproducibility? Does apt have some way to specify lock files or hashsums of the packages it is supposed to install? Or do you mean to pin version numbers of system packages and rely on that? Otherwise apt would be the point where the guarantees go out of the window already.
- seabass-labrax 2y agoDebian can pin packages to certain versions by their numbers (see dpkg(1), '--set-selections') and it does verify package integrity. I can't think of any way to pin a package to a hash like with Bazel or Nix, but the expectation is that packages are not changed after publication in dpkg repositories - and for Debian itself, that expectation is a strictly-followed rule. Therefore I would trust package pinning to work, but it's not quite as straightforward for the end-user as unique package hashes as identifiers.