On 05/01/17 09:23, Brian May wrote:
Peter Palfrader <wea...@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
