[buildd-tools-devel] Bug#786566: this is affecting us

[Roger Leigh]

On 05/01/17 09:23, Brian May wrote:
> Peter Palfrader <weasel at debian.org> writes:
>
>> It's a serious bug that makes it break in many cases, requiring the
>> sysadmin to clean up and/or reboot the system.  Whether or not it's RC
>> in the end is the decision of the release team, but this severity was
>> set after discussing this on #debian-release.
>
> Is anything being done to fix this? What is the hold up? Apparently
> there is a patch for this RC bug and the other RC bug #817236.

I'm not personally working on any fix in schroot, since it's not an 
schroot bug.

> It is kind of looking like stretch will get released without schroot
> support, or any packages that depend on it. Maybe time to forgot schroot
> and look for alternatives???

schroot is not responsible for setting up device nodes in a 
debootstrapped chroot.  We expect them to be set up correctly.  This 
isn't a Debian-specific constraint; we expect all chroots of any sort to 
be in a sane and directly usable state.

schroot's requirements are not any different here from that of the basic 
chroot(8).  Is chroot(8) equally broken here?  The mounts and other 
features schroot offers on top of that are entirely optional, and 
implementation wise is nothing more than a wrapper around chroot(2) to 
perform exactly the same job as chroot(8) with some sudo-like PAM 
authentication and authorisation.

While we could add additional mounts to the schroot fstab templates, 
it's important to understand that this is optional functionality, and 
has always been optional.  It's not a mechanism for working around 
external breakage.

Looking for alternatives to schroot is entirely your choice, but 
breaking basic system-level functionality which has been working for 
over two decades, and used for over 11 years by schroot, is I think 
something which needs careful consideration.  I'm prepared to do some 
work to ensure that schroot interoperates with contemporary systems, but 
working around breakage like this is perhaps a step too far.


Regards,
Roger