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.
Description: Digital signature