Consider upgrading to current live-build
Originally created by Tails on #5691 (Redmine)
We use a slightly modified live-build 2.x to build Tails:
That package is installed in the Vagrant build box, so that’s invisible to developers, and does not require them to take any special action.
Next thing to do is to decide if we go for upgrading live-build, on the longer term, or something else.
If we go with current live-build:
- compare the resulting packages list with Tails images built with live-build 2.x (the tasks support was removed, so we could lack a few standard priority packages)
- review all our lb config options, and make sure they are still valid and taking effect
- fix the resulting images file naming
- patch and/or overlay syslinux config to bring back our preferences that lb 3.x does not support directly anymore (see commit 3458797)
- see what breaks, report bugs upstream and possibly fix them.
Benefits from recent live-build improvements:
- new contributors can find the relevant live-build doc (sysadmin#12296 (closed))
- inject variables through
config/environment.chrootinto the chroot environment (note:
environment.binaryis broken for us, and
environemnt.chrootcan’t be used for variables whose value contains spaces)
--firmware-chroot trueinstead of manually listing all firmware packages (not usable for us, see commit 3dee0470)
- save more disk space at build time (#5940 (closed))
- the configuration tree is bind-mounted on
/root/configin the chroot, and available for hooks
- XXX: any other useful changes since the 3.x era?
Cons of upgrading to current live-build:
- It requires lots of work.
- basically all configuration files were renamed, which makes it a pain to migrate our many branches; same for a bunch of command-line switches; this will make the branch painful to review and more importantly, will make it much harder to look up stuff in the Git history of our code base
Feature Branch: feature/live-build-3.x