dependency graph for a x86_64 made on a i386 host architecture?
n3npq at mac.com
Tue Nov 7 12:41:46 PST 2006
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)
I'm phasing rpmrc out of rpm. In fact, /bin/rpm no longer reads rpmrc
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"
arguably more pleasant "amd64" which was then trumped by Intel's
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
(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
More information about the Smart