On Tue, Feb 02, 2010 at 07:59:53AM +0100, Lucas Nussbaum wrote: > On 02/02/10 at 01:07 +0100, Wouter Verhelst wrote: > > At any rate, here are some facts: > > - A package that builds differently because something is (or is not) > > installed on the build system is buggy. Period. It has nothing to do > > with the build system, it's the package. > > ... but I question that it is a bug that we want to spend time fixing. > > > - A clean chroot takes time and processing power. You need to drop and > > recreate the chroot between builds, upgrade the same Build-Essential > > packages every time you do an upgrade, copy the apt cache in and out > > of the chroot (or keep downloading the same packages over and over), > > and various other things. LVM snapshots fix some, though not all, of > > those problems, and introduce a few of their own. > > I don't know about you, but I'd rather have the buildd spend > > processing power on building packages. Having it fail at producing a > > good package because the maintainer didn't do a good enough job is > > nothing new -- they do that all the time. > > I think that the question is whether we would rather have the maintainer > spend time fixing those issues, or the buildd spend time dealing with > the consequences of using LVM snapshots. The crux of the problem is that we can provably build all packages in a clean minimal chroot, at the expense of not necessarily having all potential Build-Conflicts identified. If we build in a dirty chroot, we might potentially trip up over the odd missing Build- Conflict, but we can't prove that they are correct unless we test building with /every/ possible combination of additional packages (which is not practical, and wastes a lot of CPU time for little to no real benefit). i.e. we can have provably correct Build-Depends, but realistically /not/ Build-Conflicts. The whole point of Build-Depends/Conflicts is to be able to reliably build a package. If we start from a clean state, the need for Build-Conflicts is no longer there, except for things the developer notices on their system. It's just not worth the developer time to identify potentially conflicting packages if they aren't a problem in reality, and by starting from a clean slate we effectively reduce the need for Build-Conflicts altogether. > I personally think that if we have a way to use CPU time to solve a > problem that would require maintainer time otherwise, we should use it. Well, from my experience, LVM snapshots use /less/ CPU time than plain chroots. sbuild needs to clean up the chroot after a build, and this means removing all of the build-deps installed at the start. This can take a lot of time, certainly much more than the time taken to delete a snapshot. snapshots are copy-on-write, which makes creation very fast, and deleting them is similarly quick (and we completely skip the chroot cleanup). The obvious advantage is that cleanup can fail, and leave the chroot in a dirty state; snapshots guarantee an identical initial state for every build. In short, starting each build from a known clean "base" chroot is not an additional overhead in any cases I've seen. We also have the ability to use unionfs/aufs in place of snapshots, which are perhaps even more lightweight. And once we have btrfs subvolume snapshots (work in progress), they will be even more efficient. 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.
Attachment:
signature.asc
Description: Digital signature