[buildd-tools-devel] next sbuild release with decoupled chroot

Raphael Hertzog hertzog at debian.org
Mon Jan 18 15:45:57 UTC 2016


Hi,

On Fri, 15 Jan 2016, Johannes Schauer wrote:
>  2. change the option parsing so that mutually conflicting options cannot be
>     given anymore at the same time. See [2] for the rationale.

I'm not sure that this is a good idea... it's quite common to allow the
last option to win and all programs which are called by wrappers (and
sbuild is one of them) have often a default invocation which is
configurable in the wrapper, and you could add "--arch-all" there to
ensure you build _all.deb by default and at the same time the wrapper lets
you append more options to further tweak a specific call and here you
might want to disable that default option with a --no-arch-all that you
know will be appended after the --arch-all that you set by default.

>  3. add the first two out of three patches from the experimental release (the
>     chroot uncoupling and the adt backend). The third patch (the linux user
>     namespace backend) is far too experimental for now.

I have had no major problems with your experimental sbuild so I think it's
OK.

>  1. remove %SBUILD_CHROOT_DIR and error loudly when somebody tries to use it
> 
>  2. keep %SBUILD_CHROOT_DIR but only fill it when using a backend where it
>     makes sense

Both are acceptable IMO. But I have never used hooks so I'm not best
placed to comment on this.

> The question with option (2) is: what to do if the backend doesn't support
> direct filesystem access from the host? Should the value just be empty? Should
> sbuild just error loudly if the user tries to use %SBUILD_CHROOT_DIR with a
> backend where it doesn't make sense?

I would say yes to your last 2 questions.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/



More information about the Buildd-tools-devel mailing list