On Sat, Feb 12, 2011 at 08:57:12PM +0000, Roger Leigh wrote: > If we have a guaranteed clean build environment + package build deps, > we have as complete consistency as is practicable. > > If we have a random build environment + package build deps, we might > occasionally find something that needs a build-conflict, but we are > never going to get complete coverage, and we aren't even considering > that the conflicts might get outdated as the system evolves, and they > will bitrot and potentially cause more problems down the line. > > The former situation is simple, robust and maintainable. But the > latter, it's a virtually intractable problem, and given the lack of > concern about it up to now, it's not a major worry for most people, > and from a cost/benefit POV it doesn't look practical.
My concern is that even if Debian builds all its packages in a clean chroot environment, others may not. If I'm trying to reproduce a problem on sparc or if I'm trying to fix a bug in some package, I'm not going to set up a clean build environment just to do that. If I encounter a problem that is not reproducible in a clean environment[0], I don't want to be told that that problem isn't a bug. Don't get me wrong: I'm fine with autobuilding all packages in a clean environment. But it's simply not practical to do that in many porting or bug-fixing situations[1] and we shouldn't ignore or lessen the severity of bugs that occur in such "dirty" environments. [0] For example, packages that fail to clean properly and hence fail to build the second time around. [1] Or situations where the user may need to apply a patch that has been sent to the BTS but has not found its way to an uploaded version. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187
signature.asc
Description: Digital signature
