Re: rpm 4.1.1 and _arch

[Jeff Johnson <n3npq nc rr com>]

Ralf S. Engelschall wrote:

> 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.
>  

You are overly polite here. rpm's concept of arch is breaking badly, 
and  is a huge mess.
For example, I just added 4 new arches to rpm because I was asked to. I 
have no
idea what the compatibility matrix should be, and little idea of what 
the differences
in configuration need to be.

> 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.

If the above works for you, that's fine, have fun. Personally, I don't 
believe
that tokens like "sparc" and "svr4" are the right name space to manage,
but that's a very long and complicated discussion, not here.

No matter what, uname(2) is the wrong way to determine "arch". And 
trapping SIGILL
for an asm voo-doo instruction to detect that 64 bit kernel has 32 bit user
space and is lying in the uname(2) field is (politely) interesting as well.

Here are two problems, one on the install, the other on the build, side 
of rpm
that need thought:

1) Thin clients in K12LTSP need to supply 2 arches on the server. The 
client needs
are often different, like "i486", then the server needs, often "i686". 
And this is only
a real world deployment, with mostly compatible arches, of the more general
NFS server problem, i.e. managing an install tree for an entirely 
incompatible arch.

How should mixed server/client files be managed by rpm?

2) cross-packaging. For a real world example, H. J. Lu has a mips based 
release of
Red Hat 7.2, land a large number of elements were cross packaged.

How should cross building be supported by rpm?

73 de Jeff