[Patch] Using MACHINE_ARCH identifiers in pkg

[Nathan Whitehorn]

The following was in a deep and increasingly branched thread on the SVN 
list. I've forwarded the relevant part here. The discussion was on using 
MACHINE_ARCH codes for package architectures in pkg instead of the 
existing ones (which are equivalent) to make script-writing easier and 
improve consistency with the way the src and ports trees work. The 
patches below are designed to make transitioning the architecture 
identifiers as painless as possible.
-Nathan

------------------------------------------------------------------------

I've written two patches today. The first
(http://people.freebsd.org/~nwhitehorn/pkg_machinearch.diff) is to pkg
itself and the second
(http://people.freebsd.org/~nwhitehorn/pkg_bootstrap_machinearch.diff)
is to the pkg bootstrapper in base. These switch pkg from using
identifiers like "freebsd:11:arm:32:eb:eabi:softfp" to identifiers like
"FreeBSD:11:armeb", matching the canonical FreeBSD platform identifiers.
The strings it uses can be predicted easily from scripts, as they are
identical in all cases to the output of `uname -s`:`uname -r | cut -f 1
-d .`:`uname -p`.

I tried to avoid changing much, so the patches are pretty short.
Internally, the patch introduces a translation table to pkg that
contains all extant FreeBSD and Dragonfly BSD architectures and moves
between the ELF-based coding and MACHINE_ARCH values. This is kind of
gross, but has the least possibility for regression, and can easily be
changed behind the scenes later. Platform detection uses the same
ELF-parsing code as before. The current/previous values are also kept so
that the patched pkg can install a package marked either with an x86:64
or amd64-type architecture ID (symlinks will be needed for a little bit
on the package server to allow both clients to work). Limited testing
suggests it works well -- I can fetch and install packages fine. More
testing would be great.

One small issue is how to bootstrap the change for existing binary
package users. The modified pkg can use packages with either
architecture ID just fine, but the current one will barf on the
FreeBSD:11:amd64 package containing its own update. There are a couple
of options: manual instructions, marking that one package with the
old-style architecture ID, etc. None should be more than slightly
irritating, though. The least bumpy route, I think, is making
directories with both the old and new names, but putting only one
package in the old-named directory: a special intermediate version of
pkg marked with the old architecture ID but able to install from the new
one. Then you just have to deal with two rounds of updates without any
other intervention, which is not so bad.
-Nathan