On Thu, Aug 25, 2005 at 08:01:24PM +0200, Martin Pitt wrote: > Michael Spang [2005-08-25 12:44 -0400]: > > If they're not fixable (I don't see how this could be) perhaps we > > need a Build-Conflicts field. > > Most probably not, since buildd chroots only install the required > build-deps and build-essential,
That is not guaranteed. A buildd chroot that is not rebuilt before each build (as is the case on most build daemons) will gradually collect more and more packages when there are bugs in maintainer scripts preventing packages from being uninstalled (as happens rather frequently); so on an average buildd, there's more installed than just 'build-essential and build-deps'. Also, there are build daemons that have some packages preinstalled anyway, even if they're not build-essential, because it's either faster or convenient. Examples are debhelper (no point in not having that installed by default if 90% of packages use it, even if it's not build-essential) and on some of my machines, alternative compilers (to more easily find out whether a package that triggers a bug in the toolchain also does so with other compiler versions) > so there shouldn't actually be build conflicts. Oh, there most certainly should. If a package doesn't compile when another package is installed, and it's not possible to fix that, then you most definately need a build conflict. -- The amount of time between slipping on the peel and landing on the pavement is precisely one bananosecond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
