[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Upcoming FTPMaster meeting

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

Attachment: signature.asc
Description: Digital signature

Reply to: