Here's the main issues as I see them: [1] Existing body of work/historical precedence -- we've already got a bunch of packages with "amd64" in the name and a dpkg with x86-64 hardcoded in it (specifically, in dpkg-architecture.pl in the hash %archtable we have the key "x86-64" and the value "x86_64-linux").
[2] Possible future implementations of the x86-64 architecture. It's almost completely certain that intel will be releasing a non-amd64 implementation. [3] Compatability with some sorts of automated processes. ????? Other than [1] I don't know of any such processes. Is anyone aware of such? [4] amd64 and x86-64 require translation when compared to uname while x86_64 requires translation when put into a package name. [5] The "other distributions and organizations" aspect -- there's ample precedence for amd64 and for x86-64 and for x86_64. ... I don't see any reason why dpkg can't support both x86-64 and amd64. This would look slightly ugly when displaying known architectures but that's not a technical issue. The real issue is probably the archive issue. We could have both a Contents-x86-64.gz and a Content-amd64.gz which list the same files, but the implications of supporting this over time are troubling. I suppose it's also worth noting that we have a Contents-hurd-i386.gz, but I'm at a loss of determining the relevance of that to this situation. Anyways, I think the situation that needs to be resolved is between ftpmasters and the amd64 porting team. So we should focus on issues which are specifically relevant to each. -- Raul