[Rpm-maint] Multiple ABI architectures (parallel installation, detection, handling)

[Panu Matilainen]

Oh I knew this would happen... the send-button is a magic 
memory-enhancer in disguise. One (of probably many) forgotten bits, this 
time hopefully with working address for Dennish too:

> On 09/15/2011 01:55 PM, Jon Masters wrote:
>> All of the existing stuff assumes that if we have vfpv3 on ARMv7 we're
>> going to be running in hardfp. We can keep that notion around in the
>> very short term, but we need a longer term solution. And although we
>> don't necessarily plan actual parallel installs of different ABIs, it is
>> not technically the case that all ARMv7 systems are going to be running
>> the hardfp port. We may e.g. install an ARMv5 port therein.

 From what I've heard + read about the hardfp ABI, its not actually 
possible to parallel-install with anything else because even the dynamic 
linker has no clue whether hardfp or some other ABI was used (see 
http://wiki.debian.org/ArmHardFloatPort/VfpComparison, cheers to our 
friends over Debian side again for a nice article :) Which makes this a 
truly <cough> "unique" <cough> piece of work. I'd love to know why it 
was done that way - my layman sense thinks the compiler toolchain should 
be able to mark the ABI in the elf headers (heck this is what the whole 
hwcap thing is about).

Since the ABI difference is apparently not recorded anywhere, there's 
little chance of rpm being able to automatically do the right thing 
really, and I dunno if its worth it trying to jump through a whole lot 
of hoops for what seems an unachievable task.

One simple brute-force "solution" that should work right now is to just 
keep the softfp/hardfp "architectures" incompatible from rpm POV and 
make the assumption that hardfp ABI will be used if the system is 
capable of it. And if somebody wants to override this assumption, that's 
what /etc/rpm/platform is for (allow overriding rpm's hw detection).

Of course the entire hw-detection and arch-compatibility system is 
seriously outdated and inadequate for todays needs, back in the nineties 
systems were a lot less schizophrenic :) I've various vagueish ideas in 
this area, but the current concept of "arch" is built so deep into tools 
around rpm that fundamentally changing it is likely to be a long and 
hard road.

	- Panu -