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[0] 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
[0] 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?
Attachment:
signature.asc
Description: This is a digitally signed message part