Package: tech-ctte dpkg support for this architecture was added in 1.10.22 with the name "x86-64"; up until this point the unofficial port had been using the name "amd64" which I felt had issues -- namely that the dpkg architecture name should match the kernel architecture name as closely as possible which "amd64" does not. Several of the people working on the port have expressed outcry at this and questioned whether it was indeed my decision to select the name for the architecture. I'd therefore like the place the following questions before the technical committee: "May the dpkg and/or apt maintainers select the name of an architecture?" and if the answer to that is negative: "What name for the x86-64/AMD64 architecture should be used?" Please note that in the latter question we are only asking for a decision on the name itself and not on that architecture's status within Debian. The candidate architecture names are as follows. I've tried to be fair in listing each name's positive and negative points and tried to avoid (other than the Vendor bit, which wanted explaining) listing other candidate's positives as negatives for the rest. "x86_64" + Matches the Linux kernel architecture name $ uname -m x86_64 + Matches the architecture portion of the GNU triplet $ /usr/share/misc/config.guess x86_64-unknown-linux-gnu + Matches that used by RPM-based distributions such as Fedora, RedHat (next release onwards), and SuSE. + Its the packaging architecture name mandated by the LSB. <http://www.linuxbase.org/spec/book/Packaging-AMD64/Packaging-AMD64.txt> - Currently "_" is used as a component separator in deb filenames therefore is forbidden in both package and architecture names. Modifying policy to allow "_" in the architecture name would still disallow placing the architecture in package names (e.g. kernel-package-x86_64). Alternatively the name would have to be mangled to (e.g.) "x86-64". - "_" is also an illegal character in hostnames, the "second class citizen" work will provide ftp.$ARCH.debian.org names for mirrors depending on their participation. This $ARCH would have to be mangled to (e.g.) "x86-64". "x86-64" (favoured by dpkg and apt maintainers, and ftpmaster) + The original AMD name for the architecture. + Matches the ELF platform name $ echo /lib64/ld-linux-*.so.2 /lib64/ld-linux-x86-64.so.2 + Although it doesn't match the "x86_64" used elsewhere precisely, it could be close enough to not confuse people and gains the plus points of "x86_64" as a result without the negative mangling points. - Alternatively it's close-but-not-exactness could cause additional confusion. - There has been a convention that "-" in architecture names separates kernel and architecture for the non-Linux ports (e.g. freebsd-i386). "amd64" (favoured by members of the porting team) + The current AMD name for the architecture. + Has been the "working name" for some time, so there already exists a large collection of debs built with this despite lack of any support in the official dpkg line. + Used by Gentoo, RedHat (they are changing to x86_64 though), Mandrake (though they might change to x86_64 to conform to LSB and RPM) and the BSDs. - Vendor specific, Intel chip owners might not realise this is their architecture. (this is more of a problem than "i386" which doesn't *explicitly* say "Intel") ? The porters claim there is considerable community recognition of this name over any other, yet when they sent their "Debian AMD64 Port Ready" mail to LWN, LWN changed the title to "Debian x86_64 port ready". <http://lwn.net/Articles/89290/> "ia32e" - It's one of Intel's names for the architecture, except they keep changing their minds. Here for completeness only. "em64t" - It's one of Intel's names for the architecture, except they keep changing their minds. Here for completeness only. something else? Perhaps tech-ctte can come up with an alternate name not on the list? Scott  in that it has not yet been added to the archive. -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist?
Description: This is a digitally signed message part