Geert Stappers <[EMAIL PROTECTED]> writes: > When the cause of the buildproblem is a missing library, > then the problem will be fixed by adding the lib.
You're correct that this is usually no reason for frobbing the Architecture field. (Build-)Depends fully suffice, and have the bonus of making a package instantly buildable (without human intervention) once a dependency becomes available. Just because you think a particular library will not be ported to an arch, does not mean nobody does it. Who would have thought that people would port GTK+ to Windows? > When the cause of the buildproblem is in the package, fix the > problem there. The package maintainer hasn't to do it by himself, he > can/must/should cooperate with people of other architectures. A sign > like "!hurd-i386" looks to me like "No niggers allowed", it is not > an invitation to cooperation. I don't think your metaphor is sound. No package in main is able to forbid people to try building it (or fixing it so it does) on GNU/Hurd, M$ Windows, CP/M or what have you. The Architecture is just a hint! Perhaps a more suitable comparison is printing "not useful for dark-skinned people" on sunblocker tubes. One type of package you forgot about are those that work only on particular arches by design. I'm quite convinced that procps either compiles out of the box on the Hurd or could be modified quite easily to do. It would still be useless, though, unless someone wrote a /proc translator first. And there's already a GNU "ps", so why do that? Various other kernel related packages come to mind: modutils, ALSA, nfs-kernel-server, ... Blindly porting everything can be narrow vision, too. -- Robbe
signature.ng
Description: PGP signature
