On Sat, 05 Aug 2017, Michael Stapelberg wrote:
> Thanks for the thorough review. It took me quite a bit to address all these
> comments :).
Great to see progress being made here but I have a few ideas that might
impact how you implement all this.
I really like the idea to make it easier for people to setup everything
they need to be able to do their packaging work. Unfortunately, setting
up the sbuild chroot is only part of the answer. We also need
qemu images for autopkgtest for example. And they also need to be updated
And as you mentionned, it would be nice to be able to support derivatives
easily, not only in place of Debian, but next to the usual Debian support.
And we want this package to work for packagers on their laptop but it
would be extra cool if it could also be used on build daemons to maintain
the build chroots.
I envision a system where the "build environments" would be defined
by files in /etc/something/build-environments.d/ and we would provide
the initial file to support sid and we could have additional packages
providing more of them.
Then we would translate this in appropriate sbuild-createchroot calls
and appropriate commands to create the autopkgtest qemu images, etc.
Some further comments:
- since we would also support autopkgtest, it's probably best put in some
separate package, not in sbuild itself
- we could make it generic enough so that each "package builder" could
hook into our scripts to build/update their build environment (e.g.
chroot tarballs for pbuilder for example).
- the initial configuration file could be controlled by debconf questions,
either to disable it entirely (e.g. because you rely on configuration
management to provide the descriptions of the build environments) or
to replace the suite name and the mirror to use, it would be low
priority so as to not burden people with those questions.
Raphaël Hertzog ◈ Debian Developer
Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/