Re: Bug#918030: please provide DEB_HOST_UNAME_MACHINE
Hi!
[ Sending out this which I had sitting here on a terminal since it was
filed. :) ]
On Wed, 2019-01-02 at 15:23:03 +0100, Helmut Grohne wrote:
> Package: dpkg-dev
> Version: 1.19.2
> Severity: wishlist
> User: helmutg@debian.org
> Usertags: rebootstrap
> 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'm assuming this is to be able to cross-build these packages, as they
need the matching uname values, currently passed manually?
> 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.
While I think the idea in principle makes sense, unfortunately I'm not
sure the implementation is as straightforward.
The biggest issue is that the uname output is (or tends to be) defined
by the kernel (libc sometimes), and the same machine might have a
different name depending on these. The obvious example is amd64 on
FreeBSD and x86_64 on Linux, or sparc64 on Linux (sun4u with «uname -p»),
and sun4u on Solaris (sparc with «uname -p»).
So this would need to be a mapping per cpu+kernel or it would be just
wrong.
> 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.
One problem is that this “standard” has been defined by each vendor
for each of their operating systems, so there's a major lack of
consistency here. In many cases its usage by userland tools will make
those tools unportable.
The rationale at
<http://pubs.opengroup.org/onlinepubs/9699919799/utilities/uname.html>
mentions as much.
I think there are different kinds of usage though, and I'd like us to
consider them distinctly. One is to decide to enable features per
kernel or cpu, and I think those are generally wrong, and should be
considered buggy, and targets to fix. The other is when used as part
of some interface naming, mostly for low-level system software source
organization, for example to use as the location on the filesystem for
some source file. Even though if even there it might arguably be a
problem with the original interface, for example on Linux that has
been mainly fixed by kbuild, where that location is defined by what
headers are being used to build the modules.
> 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.
Right, and many other example. There's
<https://en.wikipedia.org/wiki/Uname> for a limited number of entries,
or «/usr/share/misc/config.guess» itself for a more detailed one.
> 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.
When it comes to dpkg, whether an architecture it supports is a Debian
release architecture is of little significance. And as mentioned above
I think this information would be required anyway for the mapping to
be correct at all.
On Thu, 2019-01-03 at 06:29:23 +0100, Helmut Grohne wrote:
> On Wed, Jan 02, 2019 at 05:49:48PM -0800, Jonathan Nieder wrote:
> > Interesting. Can you give an example of a package that would benefit
> > from this?
Right, that's also the first thing that came to mind, indeed thanks
for asking! :)
What the following list show is that at least currently there's a need
to provide this information if one wants to cross-build these packages
automatically. But I think it also shows that in many cases the uname
handling in upstream is also wrong, for example:
> https://sources.debian.org/src/klibc/2.0.4-14/Makefile/?hl=33#L33
Needed to map to its internal notion of host architecture, the mapping
would need to stay, as it does not match neither uname nor dpkg
architectures.
> https://sources.debian.org/src/lm-sensors/1:3.5.0-3/Makefile/?hl=80#L80
prog/dump appears to support at least also powerpc (and AFAIR ISA and
EISA were supported by many other architectures), but the Makefile
does not include it. i786 is also not handled.
> https://sources.debian.org/src/libselinux/2.8-1/src/Makefile/?hl=111#L111
Used only yo select whether it can use a compiler flag. Could do with
a «configure»-style check instead I guess.
> https://sources.debian.org/src/dmidecode/3.2-1/Makefile/?hl=46#L46
Fails to handle i786.
> https://sources.debian.org/src/glew/2.1.0-3/config/Makefile.linux/?hl=4#L4
This one seems to be just wrong, in the Debian context.
> You'll find lots with:
>
> https://codesearch.debian.net/search?q=uname+-m+path%3Aakefile
>
> Here is an implemented mapping, that could likely go away:
> https://sources.debian.org/src/tbb/2018%7EU6-4/debian/rules/?hl=33#L27
I don't think that would be the case, as I'm not aware of any system
using either intel64 nor ia32 as uname output? And well the arch could
stop being passed, but then again this fails to handle any i386 that
is not an i686 (on non-Debian systems!).
Thanks,
Guillem
Reply to: