[buildd-tools-devel] Bug#786566: this is affecting us
Roger Leigh
rleigh at codelibre.net
Thu Jan 5 10:08:02 UTC 2017
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
More information about the Buildd-tools-devel
mailing list