Adding a MACHINE_ARCH note

[Warner Losh]

On Jul 10, 2013, at 10:03 PM, Tim Kientzle wrote:

> On Jul 10, 2013, at 1:27 PM, Warner Losh wrote:
> 
>> On Jul 10, 2013, at 1:55 PM, Baptiste Daroussin wrote:
>> 
>>> Just tell me where I can get the right string and how can I check the compatible
>>> ABI and pkgng will switch to it. I would have love this to happen a year and a
>>> half before that would have saved me from having to prepare a migration path,
>>> but better late that never :)
>> 
>> uname -p is the first cut. It is intended to completely describe the main ABI of the current machine.
>> 
>> However, you're right. The kernel should export a list of ABIs that it supports. We don't currently do that.
>> 
>> I'd propose hw.abi that will export the ABIs the kernel supports. 
> 
> How does this work in the case where I'm building an armv6 image
> on an i386 system?   Or doing package installs directly on my NFS
> server, which isn't the same architecture as the diskless systems
> running from it?  For that matter, just querying the kernel would
> give wrong results for an i386 jail running on amd64, where the
> kernel might support amd64 but 64-bit libraries aren't available.

Sounds like a good number of cases for an override flag.

> In all of these cases, it's the ABI of the target system that matters,
> and there's no running kernel to query.

Usually you have a kernel to query. When you don't, the user will have to tell the pkg tools what to use.

> This is why pkgng today looks at ELF information in /bin/sh to
> determine what is supported by the target system.

But that's still not right, since it will only allow you to install one ABI. It would be impossible to install i386 packages on an amd64 machine, so I'm not sure this is a winning argument.

> How can we code information equivalent to uname -p in
> a place where it can be statically determined from an image
> of a non-running system?

I would wager that most of the time, uname -p is what you want. Since you are trying to second guess what's going on, while still allowing for a wider variety of things, we'd need to have some automatic way of determining what's supported, but also some way to override it.

Most of the time, pkgng is used by a user installing packages on the system he or she will be running on. We should optimize that path, while still allowing others to work with an override flag. Much like we default to the current running system in buildworld, unless you override, and we don' t allow you to install on a system where TARGET_ARCH != MACHINE_ARCH unless you specify an override.

Warner