[buildd-tools-devel] Bug#403246: Bug#403246: sbuild’s shortcomings

[Roger Leigh]

On Wed, Feb 16, 2011 at 11:03:15AM +0100, Thorsten Glaser wrote:
> why not “just” write something that walks like an sbuild,
> quacks like an sbuild, and calls cowbuilder?
> 
> This would solve all the problems with tearing down pak-
> kage installation etc.
> 
> … except #363193 (I think pbuilder too needs some love,
> or team maintenance).

cowbuilder has one major flaw: the copy-on-write is implemented by
LD_PRELOAD, as a shared library copied from the host system.  This
precludes the build environment from having a glibc incompatible with
the host, since it would break the copy-on-write functionality.
Additionally, the LD_PRELOAD symbol coverage may become outdated as
glibc adds new symbols, resulting in some actions overwriting the base
environment.  Example: the new openat/mkdirat variants of the basic
system calls.  These also need preloading.  And it will break every
time a new symbol needing preloading is added.

I did look at it in detail a year or so back, but it's really too
fragile to use long-term.  It's not that it doesn't work, it's that
continued reliability is not guaranteed.

sbuild has the ability to host alternative architectures in the
chroot; currently 32/64 bit versions of the same arch e.g.
i386/amd64.  LD_PRELOAD would break here.  Soon, we will also
gain the ability (via schroot) of using qemu-$arch-static and
binfmt-misc to run binaries from any arbitrary arch inside the
chroot to do builds for non-native architectures; here we also
can't do copy-on-write.

sbuild itself relies entirely upon schroot to do its virtualisation.
cowbuilder-like support could potentially be added to schroot to give
sbuild this functinality, but it would require some refactoring of
schroot to permit this.  I can put it on my TODO list, but I'm afraid
it won't be a priority item.

The existing lvm-snapshot support is both fast and (bar kernel bugs)
completely reliable WRT data being genuinely copy-on-write.  We now
have btrfs snapshot support when is even quicker to create snapshots,
but currently performs badly with dpkg; hopefully this will be
addressed by dpkg now squeeze is out.  While these require setup by
the sysadmin, they both have the copy-on-write guarantees we need.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/buildd-tools-devel/attachments/20110216/38faf3e7/attachment.pgp>