[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

testers wanted: sbuild and build-dependencies

Hi folks,

sbuild 0.60.4 has just been uploaded to unstable, and we would very
much like to get some feedback about a new feature it includes.
If you're a user of sbuild, this means you!

When sbuild builds a source package, either locally or on a buildd,
it uses a "dependency resolver" to determine which binary packages
to install and/or remove from the build chroot to satisfy the
Build-Depends, Build-Conflicts (and -Indep variants) specified by
the package.  Historically, sbuild has used an "internal" resolver,
included with sbuild to do this task.  However, it has a number of
bugs and deficiencies and we would like to move to a more modern
resolver which can properly support things Debian Policy says we
should support, such as:

• Handling correct removal of all Build-Conflicts
• Correct selection of alternative dependencies
• Correct installation of virtual packages
• Proper support of versioned dependencies, including the above

The internal resolver fails under certain circumstances for all of
the above, or simply doesn't support them at all.

A new "aptitude" resolver has been written by Marc 'HE' Brockschmidt.
This creates a dummy "dependency package" which is installed and
contains Depends and Conflicts for all the appropriate Build-Depends
and Build-Conflicts, and uses aptitude to install and remove the
appropriate packages to satisfy them.  This has been in use on our
experimental buildds for about a year, and we now want to look towards
making it the default.  However, we need some more widespread testing
to make sure the dependency resolving doesn't result in inconsistent
installation of packages and hence inconsistent library dependencies
or break building of any packages etc.

The aptitude resolver may be enabled by setting
in your /etc/sbuild.conf or ~/.sbuildrc

You can then build your packages with sbuild like normal.  What
we are interested in are things like:

• Outright build failures (e.g. due to unsatisfiable/uninstallable
• Different packages being installed compared with the internal
• Inconsistent packages being installed (depending on if other
  packages are installed or not)
• Anything odd or unexpected
• Success (if it works without problems, this is also nice to know!)

Making sure the build chroot is fully updated and upgraded prior to
testing can avoid false positives!
Note: when building packages for upload, set
(or comment out the line) to use the internal resolver to make sure
the same resolver is used as on the buildds.

Feedback can be sent to buildd-tools-devel@lists.alioth.debian.org

Many thanks,

  .''`.  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.

Attachment: signature.asc
Description: Digital signature

Reply to: