dependency graph for a x86_64 made on a i386 host architecture?

[Jeff Johnson]

On Nov 7, 2006, at 2:05 PM, Mauricio Teixeira (netmask) wrote:

> Em Ter, 2006-11-07 às 15:07 -0500, Jeff Johnson escreveu:
>
>> Dumping archscore is under active consideration as we speak.
>
> May I ask why? (Just curious)
>

Sure.

I'm phasing rpmrc out of rpm. In fact, /bin/rpm no longer reads rpmrc  
compatibility
tables in rpm-4.4.7.

The idea of arch compatibility ordering has never worked well outside of
	i386 -> i486 -> i586 -> i686 -> i786 -> i886 -> i986
(yes, rpm used to carry on beyond i686 many years ago).

WRTO x86_64, the person who wrote the compatibility rules (not me)  
dinna get it "right".

Then there is AMD marketing, which overruled engineering's "x86_64"  
with the
arguably more pleasant "amd64" which was then trumped by Intel's  
"ia32e".

In other words there are beaucoup aliasing problems with the existing  
arch name space.

On non-*64, there are perhaps 6 or 8 too many ppc architectures for  
hysterical reasons
(I was asked to invent the names for 3 ppc architectures without any  
knowledge of ppc).

What is insanely gross is that arch detection for ppc* depends on  
trapping SIGILL to
detect differing cpu firmware on a ppc64 pretending to be a ppc  
through setarch. Got that?

With qemu and multilib and xen and ia64 emulating both ia32e and  
ix86, well, enough is enough,
hacks on top of hacks on top of hacks.

Simpler is better, add --target=foo, and voila! you are running on  
the "foo" architecture as far
as rpm-4.4.7 is concerned.

I suggest similar for all applications that use rpmlib, and am  
working with Gustavo to see how
he wishes to handle arch compatibility in smart. Other applications  
like yum and up2date
have long since internalized their own concept of "compatible".

73 de Jeff