Your message dated Sun, 3 Nov 2019 19:11:58 +0100
with message-id <[email protected]>
and subject line Re: Bug#918030: please provide DEB_HOST_UNAME_MACHINE
has caused the Debian Bug report #918030,
regarding dpkg-architecture: Provide DEB_HOST_UNAME_MACHINE
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
918030: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=918030
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: dpkg-dev
Version: 1.19.2
Severity: wishlist
User: [email protected]
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 [email protected] 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
--- End Message ---
--- Begin Message ---
Control: tag -1 wontfix
Hi!
On Fri, 2019-02-15 at 06:39:53 +0100, Helmut Grohne wrote:
> Thank you for the details. I'll shift focus on removing uname usage
> then. The trade-off wrt. maintaining this in dpkg vs. fixing upstreams
> is not the one I envisioned.
>
> You've made a very good case for closing this as wontfix.
Ok, then let's do this. :)
Thanks,
Guillem
--- End Message ---
