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

[Johannes Schauer]

Hi,

I just released sbuild version 0.68.0-1 to unstable and rebased my patches for
uncoupling the chroot from the host system, the adt-virt-* backend and linux
user namespace backend [1] into version 0.68.0-1.0~exp1 in experimental.

With the next release I'd like to do three things:

 1. remove the --arch-all-only option which was given a deprecation warning in
    this release. See [2] for the rationale.

 2. change the option parsing so that mutually conflicting options cannot be
    given anymore at the same time. See [2] for the rationale.

 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'd like your comments on this plan.


One open question about (3) is that the percentage escape %r or
%SBUILD_CHROOT_DIR used to substitute the chroot root directory as seen from
the host in external command invocations will not always be useful anymore.

I will definitely add a new percentage escape, lets call it %e or
%SBUILD_CHROOT_EXEC which contains the command that can be executed on the host
to execute a process inside the chroot. Naturally the value of this will differ
between different backends. For the schroot backend it will be along the lines
of:

    schroot -d / -c ${schrootid} --run-session -q -u root -p --

And then the caller can extend this line with the command they want to run. By
opening a pipe from or to that command, data can be exchanged with the chroot.

The question is what to do about %SBUILD_CHROOT_DIR. It will still be useful
with certain backends like schroot. But it will not be useful in other
situations like for adt-virt-qemu, adt-virt-ssh or where user namespaces are
involved. I see two options:

 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

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?

Thanks!

cheers, josch



[1] http://lists.alioth.debian.org/pipermail/buildd-tools-devel/2015-December/010172.html
[2] http://lists.alioth.debian.org/pipermail/buildd-tools-devel/2016-January/010490.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: signature
URL: <http://lists.alioth.debian.org/pipermail/buildd-tools-devel/attachments/20160115/83196b1c/attachment.sig>