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

Roger Leigh rleigh at codelibre.net
Thu Jan 5 17:12:51 UTC 2017


On 05/01/17 10:08, Roger Leigh wrote:
>
>
> 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.

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



More information about the Buildd-tools-devel mailing list