On Mon, Feb 14, 2011 at 08:53:13PM -0600, Raphael Geissert wrote: > Roger Leigh wrote: > > 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. > > Am I missing something or your really don't need none of the following: > > > What is needed: > [...] > > - with a lot of disc space > > - and a lot of spare CPU cycles > > - 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. > > ? > All you seem to want is the resolver's results, nothing else. > In fact, a simple, clean, chroot running apt-get --dry-run build-dep, and > aptitude --simulate build-dep should do it. I don't just want to test the resolver, which I agree wouldn't need this. I also want to know the number of build failures each resolver results in. While this would show up from an altered package list, an altered package list might not mean anything bad at all in most cases, the discrepancies due to using a different resolving algorithm, which would not alter the correctness of the outcome. Having the complete build logs means we can then examine them in detail to look at exactly what went wrong. 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.
Description: Digital signature