On Wed, 02 May 2018 at 08:21:41 +0200, Johannes Schauer wrote: > Unfortunately, according to Martin [1] it is out of scope for autopkgtest to > also add support for making persistent changes to the underlying backend. This > in turn means, that an operation like: > > $ sbuild-update -udcar unstable > > will never work for the autopkgtest backend.
This has the same predictability issues as upgrading a system rather than reinstalling it: how do we know that the result of an upgrade is the same as the result of reinstallation? For real systems we support upgrades anyway, because the value of carrying over configuration changes is greater than the cost of some unpredictability; but sbuild chroots don't/shouldn't have configuration (all the configuration is outside the chroot on the host system), so that doesn't really apply. In general an upgrade won't do the same thing as a reinstall, because old packages that used to be important but are no longer will tend to remain installed: - packages that used to be Essential but are not any more, because full systems need them but containers and chroots don't (init; hopefully sysvinit-utils and e2fsprogs at some point) - packages that used to be transitively (build-)Essential or important but are no longer the preferred choice (old major versions of gcc; maybe old major versions of Python if a version of Python becomes build-essential) - superseded versions of libraries (older SONAMEs of libasan, libpcre, libncurses, etc.) As far as I'm aware, the production buildds never upgrade their chroots: instead they re-bootstrap and discard the old version. Docker strongly encourages the same approach. In my build tool Vectis <https://github.com/smcv/vectis>, which uses autopkgtest virtual machines, I use the same approach for virtual machine images, sbuild tarballs, piuparts tarballs and lxc images: never upgrade, only replace. I don't currently use autopkgtest as a sbuild backend, because one of the design goals of Vectis is that it defaults to the same mechanisms as the production infrastructure, so that if it works locally for me it will work on Debian machines too; but it does know how to re-bootstrap sbuild tarballs separately. smcv
