Re: rpm 4.1.1 and _arch

["Ralf S. Engelschall" <rse+rpm-list engelschall com>]

On Fri, Sep 19, 2003, Jeff Johnson wrote:

> >Just a quick question (probably for Jeff). With rpm 4.1.1, when I use
> >rpmbuild directly on x86, %{_arch} is set to "i386" by default, but when
> >using "--target i386", it is set to "noarch". Seems quite confusing, or am
> >I missing something?
> [...]
>
> target_cpu is probably what you are looking for rather than arch.
>
> _arch == noarch. if just 4.1.1, there's something screwy in the
> config. equally likely that its been there for years.

As a sidenote, I've been fighting again this whole platform
identification stuff recently for OpenPKG and found that RPM
historically is a little mess here.

If you look at

   http://cvs.openpkg.org/openpkg-src/openpkg/rpm.patch.feature

under "platform id canonicalizations" you can see that I've disabled the
internal platform uname(3) fiddling and use the external "platform" file
for directing RPM to the pre-determined platform id. And this in turn is
created once and more accurately with a new OSSP platform implementation
you can see under

  http://cvs.openpkg.org/openpkg-src/openpkg/platform

And within our macro overriding file (see first macro definition there)

  http://cvs.openpkg.org/openpkg-src/openpkg/rpmmacros

I've canonicalizing the various legacy RPM %{_xxxx} macros to this
information, so RPM's knowledge about all this is equal throughout all
macros (keep in mind that OpenPKG does no cross-platform building, so I
can do it easier here, because host and target is the same).

With this new platform identification we especially distinguish between
platform class, product and technology now. Because, for instance,
OpenPKG RPM binary packages require the platform product id (else a
Debian and a RedHat binary both would be simply labeled "ix86-linux2.4"
while we want "ix86-redhat9" and "ix86-debian3.0"), while during build
checks you usually need product technology or class information. We do
this with our local OpenPKG macro %{l_platform -c|-p|-t}. Here is an
example:

                            FreeBSD         Linux          Solaris
class      %{l_platform -c} ix86-4.4bsd     ix86-lsb1.2    sparc-svr4
product    %{l_platform -p} ix86-freebsd4.8 ix86-redhat9   sparc64-solaris9
technology %{l_platform -t} i686-freebsd4.8 i585-linux2.4  sun4u-sunos5.9

As you can see, an OpenPKG source RPM "foo-V-R.src.rpm", if built on a
RedHat 9 box for an OpenPKG instance /xx, will result in a binary RPM
"foo-V-R.ix86-redhat9-xx.rpm" while the same package on a Debian 3.0 box
leads to a distinguishable "foo-V-R.ix86-debian3.0-xx.rpm". But during
building this package, the package iself is not required to know all
those Linux products it can be built for. Instead it can (if needed)
easily check for the underlying platform technology (which is Linux
here) by checking "%{l_platform -t}" instead of "%{l_platform -p}". Or
(sometimes also reasonable) it can just check for the platform class
with "%{l_platform -c}" (which is LSB here).

I know that this stuff might be overkill for RedHat's own RPM, but is
essential if RPM is deployed on multiple platforms as OpenPKG does. But,
at least the canonicalization of the various arch/os macros I strongly
suggest for RPM. Because the current default settings are too confusing
IMHO.
                                       Ralf S. Engelschall
                                       rse@engelschall.com
                                       www.engelschall.com