[Andreas Barth] > > "machine" translates with partition btw - though the two different > > partitions should be in different physical locations, for obvious > > reasons. Yes, we want a redundancy for good reasons. [p2] > Which is very arbitrary to me, machine to me means physical box with > hardware and software doing stuff. So this requirement is very much > arbitrary and without any reasonable foundation. I don't think anyone ever said an official buildd cannot be used for any other purpose. The s390 box is used as a buildd, but is also used for other things - I don't see the problem. Of course, it's probably a bad idea to give out random shell access to the buildd's OS instance. 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. > 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. Peter
Attachment:
signature.asc
Description: Digital signature