On 05/01/17 10:08, Roger Leigh wrote:
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.
Very sorry, replying to the wrong ticket here. Got confused with #817236.
For this specific issue with mount options, I've been following along
but so far the discussion and proposed patches in this bug haven't
reached a definitive conclusion with a consensus, so I'm waiting on an
informed decision before I apply anything upstream. I don't myself have
the expertise to judge what the right action is here, so I'll defer to
others for what's best.
Speaking frankly, I'm appalled that such gratuitous breakage through
incompatible changes to the functioning of the base system was and is
considered at all acceptable. There's over 20 years of software
development and admin experience on Debian, 11 for schroot, and there's
a lot of code, and a lot of sysadmin-related scripting and expectations
which makes assumptions about how mount(2) and mount(8) will behave.
schroot is just one tool amongst many which expects them to work in the
traditional, documented and most of all portable way. Changing
fundamental default system-wide behaviour on a whim is not what I would
expect for a mature and established system. I'd expect rather more
considered and measured incremental change, which is something I've
tried to pay proper attention to in my own work. As an opt-in option
for certain mounts, it would be fine, but enforcing it system wide is
somewhat cavalier and inconsiderate of the multi-decade established
semantics which we expect. This significant change in attitude is one
of the factors behind my no longer actively using or developing on
Debian. Like it or not, it's become a mature system, and that brings
with it some responsibility toward backward compatibility even when we
might want to rip it all out and start over with something new and exciting.
Too late to fix that now, so I'll consider applying upstream whatever
makes most sense. However, I must stress that schroot must remain
portable to non-systemd-Linux, GNU/Hurd, GNU/kFreeBSD and FreeBSD, and
any patches must not break this support.
Roger
