[buildd-tools-devel] Wanted: system/volunteer to do whole-archive rebuild (×3) to test sbuild

[Roger Leigh]

Hi folks,

sbuild, which does the job of building binary packages on our buildds,
uses a built-in build-dependency resolver ("internal") to work out
what packages need installing/removing in order to satisfy a package's
Build-Depends and Build-Conflicts.  Unfortunately, this has a number
of bugs, e.g. #403246, as well as serious maintainability issues which
make it less than desirable.  Last year, we introduced two new
resolvers, "apt" and "aptitude" which delegate the somewhat complex
build dependency resolving to the tools which are best at it.

Now that squeeze is out, it would be great if we could revisit the
discussion about which build dependency resolver we want to use on
our buildds.  The main concern here is that switching resolvers will
change exactly which packages are installed in some situations, mainly
in the case of packages depending on alternatives, which could lead to
different packages being installed, inconsistent selection of packages
being installed, or broken package builds.  The intenal resolver was
dumb: it just always chose the first dependency even if it was
unsatisfiable.  aptitude is far cleverer; apt somewhere in between,
though we've tweaked aptitude to behave as close to stupid as we can.

However, in order to understand the implications, we need concrete
data about exactly how they differ, and under what situations.  What
I would like to do is a rebuild of the squeeze archive (since it
won't change between builds) using each of the "internal", "apt" and
"aptitude" resolvers.  Since sbuild records the complete set of
packages available immediate before the build starts, we can extract
this from the build logs, find any differences, and determine what
causes them, if and when they occur.

What is needed:
- a stable/testing/unstable system
- with a lot of disc space
- and a lot of spare CPU cycles
- sbuild 0.60.9-1 (to be uploaded soon; or pull from git)
  [with automatic update/upgrade disabled, and logging to alt log dir
   for each run]
- schroot
- LVM
- The builds will use a cleanly debootstrapped squeeze on an LVM LV,
  which can be freshly snapshotted for each build, as on buildds.
  This will make the comparisons between resolvers identical.

We don't need to store the built binaries, so they could be thrown; we
just need to store the build logs.  It might also be possible to skip
some of the archive; we only really need a representative sample to
do a realistic test, if time and disc space are issues.

If there are any project machines available that could do this, that
would be great!


Many thanks,
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/20110214/731c1a68/attachment.pgp>