Re: Bug#918030: please provide DEB_HOST_UNAME_MACHINE
Hi Guillem,
On Fri, Feb 15, 2019 at 02:28:32AM +0100, Guillem Jover wrote:
> [ Sending out this which I had sitting here on a terminal since it was
> filed. :) ]
Thank you for no longer deferring your insightful reply.
> On Wed, 2019-01-02 at 15:23:03 +0100, Helmut Grohne wrote:
> > 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.
I did not foresee this. In my view this "breaks the camels back".
Maintaining this value for each arch (as opposed to each CPU) is
impossible. At best, dpkg could provide the value for a selected few
architectures and leave the field empty for others.
> 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.
I don't think we need to argue whether the interface is broken. What
prompted the filing of the bug was an evaluation of effort: What is
easier? Fixing all users of uname or coming up with "good enough" fake
values.
Regardless of whether dpkg now gains the requested feature, I think this
bug report will become very useful in pointing users of uname to.
> 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.
Again, I am not opposed to fixing the root cause. Thus far I felt that
"cross building" was an unconvincing reason though. If there are more
problems resulting from uname use, then maybe upstreams are listening to
them.
> 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.
I don't think that universal availability of DEB_*_UNAME_MACHINE is
required (nor feasible). Not every architecture is used for cross
building and when you start using it, you can simply add the value.
> 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:
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.
Helmut
Reply to: