On Mar 26, 2012, at 12:31 PM, Henri Gomez wrote:
>> Use "noarch". What would be kinda spiffy is to automate lipo
>> under RPM control and strip out the unused architectures
>> in universal executables (and if one "trusts" the automated dependencies
>> are accurate) the libraries.
>>
>> I've also been waiting (like 8 years now, sigh) to internalize MACH-O
>> like ELF in RPM. Using "helper" scripts like find-requires/find-provides
>> is fine of now, but an implementation in C is precise and accurate
>> and maintainable in a way that scripts will never be.
>
> We should stay careful about architecture.
Well my mantra is this:
RPMTAG_ARCH needs to DIE! DIE! DIE!
Seriously: in the real world (i.e. not linux) there are several
important identifying attributes that need to be controlled for.
And there are some seriopus pending changes in order to handle
ARM platforms, which have "features" that are disabled/enabled.
Already there is serious confusions attempting using "architecture"
for Linux/ARM. Each variant "feature" leads to a new "architecture"
forcing some "compatibility" chains that are simply fictions (i.e. there
is more compatibility than promised by choices for RPM arch compatibility).
>
> Apple moved from 68k to PowerPC, and then to x86 (32 and 64 bits).
> And who knows what future processor they could bring in desktop :)
>
It will more than likely be an A6 ;-)
> Also, Xcode build tools may stop supporting PowerPC in a near future,
> so packages will lost their 'universal' architecture.
(aside)
If you have Xcode skills, I'd like to see RPM build under Xcode.
I'm still in denial there however ;-)
> I recall some packages who need to go up to Assembly level and I'm not
> sure OSX build tools could embed many builds in a single binary.
>
> But for now, x86 (32/64bits) is a general consensus
No iPads for you eh?
73 de Jeff
______________________________________________________________________
RPM Package Manager http://rpm5.org
User Communication List rpm-users@rpm5.org
