Push lockfiles functionality into aptly (upstream)

[wmanley]

lockfiles are arguably the most generally interesting idea in apt2ostree. The same technique can be applied to other container systems like docker, and might even be useful on host systems. There would be value in separating out the bits of this project that deal with generating lockfiles into other projects for broader consumption.

Specifically there are two areas:

1. Generating the lockfiles
2. Applying the lockfiles

These should be considered separately.

Generating the lockfiles

We generate lockfiles using a Python API and passing in the packages we want. This generates a ninja file with rules to generate the lockfile. Running the ninja file depends on Python, aptly, ninja and apt-tools.

If we want the lockfiles to be used more widely it makes sense to reduce the number of dependencies - therefore making it easier to deploy. This functionality should be moved into aptly itself and implemented in go. Then in this project we just integrate it with the build system.

The command could look like:

aptly lockfile update config.ini

Which would take a multistrap config file "config.ini" and generate config.ini.lock. We would then modify the build system to generate these config files and call aptly lockfile update accordingly.

TODO:

• Move multistrap ini parser to aptly/go
• Call aptly with multistrap ini from apt2ostree
• Propose aptly lockfile in aptly upstream

Here are the current aptly patches:

stb-tester/aptly@cb35058

Applying the lockfiles

apt2ostree essentially is a mechanism for applying these lockfiles to produce ostree images.

Lockfiles are a useful technique even in the absence of ostree, so for broader acceptance of this technique there should be other implementations. It might make sense to have apt (or possibly dpkg) be able to do this itself. It could then be used for docker images like so:

FROM ubuntu:20.04
ADD lockfile.lock /lockfile.lock
RUN apt apply-lockfile /lockfile.lock
...

TODO:

• Discuss this with apt maintainers