[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