Hi everyone: I'm mailing this to both debian-policy and debian-devel, because I'd like to get the perspective from both sides -- the policy one, and the "in practice" thinking.
Currently architectures are defined as a string which contains two parts, an operating system name, and a microprocessor architecture. I sort of object to the idea of the field being called Architecture rather than Platform, but the choice has already been made and I guess we're stuck with it. Anyway, the idea is that we have pairs like: linux-i386, meaning it's a Linux operating system, with i386 processor architecture. What I am wondering is, if we have the full set of operating system names, currently: darwin freebsd hurd kfreebsd knetbsd kopensolaris linux netbsd openbsd solaris And we have the full set of processor architectures, currently: lpia sh4eb sh4 alpha mipsel ia64 avr32 sparc armel armeb arm mips m68k s390 sh3 s390x hppa sh3eb powerpc m32r amd64 i386 ppc64 Does that mean we should be able to just pick something from both lists, and turn that into a valid string to put in the Architecture field? solaris-armel, for example. The reason I ask is because `dpkg-architectures -L' outputs the strings concatenated together, and I'm not totally sure if all the possible combinations are there (there are 212 combinations output by: dpkg-architectures -L | wc -l). There are 23 processor types, and 10 operating systems by my count, which means there should be 230 combinations of the two, so some are missing, or perhaps my math is wrong. My question is, does anyone know of cases where a given operating system and architecture does not constitute a valid platform (ie, Architecture in the d/control file sense). I am trying to write a validating parser, so I need to be able to pick out impossible platform combinations, if there are indeed any. Another question might be, why are the given operating systems unsupported on those architectures? Is that likely to change in the future? Cheers, Jonathan Cc: My Google Summer of Code project mentor, Dominique Dumont. -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
