Bug#918030: please provide DEB_HOST_UNAME_MACHINE

[Helmut Grohne <helmut@subdivi.de>]

Package: dpkg-dev
Version: 1.19.2
Severity: wishlist
User: helmutg@debian.org
Usertags: rebootstrap

Hi,

I find myself repeating a mapping from Debian architectures to the
typical output of uname -m (and occasionally -s) in various packages.
Copying such code is going to be a maintenance nightmare, so it should
live somewhere central. I propose dpkg-dev/dpkg-architecture.

I propose that dpkg-architecture gains three new variables
DEB_{BUILD,HOST,TARGET}_UNAME_MACHINE. The content of the variables
shall be the typical output of uname for that Debian architecture and a
matching kernel (i.e. not x86_64 on i386 when using a 64bit kernel). I
propose that the values are added to cputable. We can add a new column
and increase the format version. Indeed, cputable already contains the
reverse mapping: Given a `uname -m`, one can use the config.guess regex
(column 3) to get the Debian CPU name.

Rationale:

Regardless of whether we like that people parse `uname -m`, we
acknowledge the fact that people do that. `uname -m` has become a
standard interface. Rather than telling people to not do that, we should
provide a standard way to supply the value.

While DEB_*_GNU_CPU is a close match, it yields powerpc64le for ppc64el
while `uname -m` results in ppc64le. For armel, an expected value would
be armv7l, but DEB_*_GNU_CPU yields arm.

We may consider providing DEB_*_UNAME_KERNEL as its use is similarly
frequent. However, its utility is fairly limited given that there are no
non-Linux release architectures at present.

I've added debian-cross@lists.debian.org to X-Debbugs-Cc to expose the
proposal to a wider audience. Are the proposed semantics useful? I guess
implementing the feature is a simpler matter. What do you think?

Helmut