[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