Hi, > The "reasonable foundation" for having a redundant buildd in a separate > physical location is, I think, well-established. Any random facility > can lose power, perform big router upgrades, burn down, etc. Debian > machines also seem to be prone to bad RAM, bad power supplies, bad disk > arrays, and the like, and these things can't always be fixed within a > tight time window. > The problem is not requiring a redundant buildd, the problem is the arbitrary limit on the amount of 'buildd machines' of 2. > > Except that arch-specific package has always meant 'contains arch > > specific code', not 'does not make sense to run on this arch'. So > > this clause doesn't cover all cases. > > Packages can be confined to specific architectures even in cases where > they're written portably. For example, I just looked at the > isapnptools source and I don't see anything particularly non-portable > in it. (It does require a concept of iopl().) But it's still useless > on platforms that don't have ISA busses, so it claims "Architecture: > alpha amd64 arm i386". And I don't remembering seeing anyone wanting > to change this, even before isapnptools was removed from unstable. This is still somewhat arch specific code as it assumes iopl and the availability of an isa bus. I'm more thinking of packages which require a lot of RAM to build and run and are thus useless on archs which generally don't have that much RAM for example. Cheers, Peter (p2).
Attachment:
signature.asc
Description: Digital signature