[buildd-tools-devel] Bug#710073: Bug#710073: Bug#710073: sbuild: add copy-on-write support

[Samuel Bronson]

Roger Leigh <rleigh at codelibre.net> writes:

> On Fri, Jul 05, 2013 at 10:15:07AM -0700, Geoffrey Thomas wrote:

>> Hasn't overlayfs support been in schroot since 1.5.2-1 (May 2012)? I
>> don't think any more support is needed on the sbuild side. Ubuntu
>> seems to be making active use of overlayfs chroots -- mk-sbuild from
>> ubuntu-dev-tools 0.136 (November 2011) onwards makes them, and they
>> carry no patches to schroot and no relevant patches to sbuild.

Might be nice if the "type=" description in schroot.conf referenced the
"filesystem union chroot" options section as applying to "directory"
chroots?  They sound rather unappealing compared to the snapshot options
there.

>> By the way, regarding cowdancer and LD_PRELOAD, I semi-recently
>> learned about fakeroot-ng, which implements fakeroot using ptrace
>> instead of LD_PRELOAD and is therefore more reliable. I wonder if
>> the same approach could be applied to cowdancer. (I've long wanted a
>> "fakeschroot" that doesn't require elevated privilege in order to
>> build things....)
>
> If such a thing is possible, that would be very interesting.  I
> don't think I'll have time to look at it myself in the near
> future, but I'd certainly support any work on it.  Removing all
> need for root privileges for sbuild would be a great achievement;
> I'd certainly be happy to remove the need for root in the build
> chroot.

Using ptrace() has one important drawback: there can be only one ptracer
of any given process.  This would make it tricky to allow using more
than one such tool at a time: for this to work, either the tools would
all need to be in league, or the outer tools would all have to emulate
ptrace() in addition to fulfilling their actual purposes.

I suppose it's a bit of work to make LD_PRELOAD-based tools play nicely
others that override the same symbols, but emulating ptrace() using
ptrace() is not my idea of a good time.

(Also, I can't help but wonder about the performance cost of having TWO
ptrace stops for *every* syscall in *every* inferior process, and it
just gets worse with the ptrace() emulation ...)

Also note that some packages, like gdb for example, have rather good
reason to use ptrace() themselves during the build.  (Say, running the
testsuite.)

-- 
Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!