Goswin von Brederlow wrote: [snip] > > Then an i686 package will claim to support ia32 ABI, but it will > > fail on an i486 CPU, which claims to provide an ia32 ABI. > > No, it will be uninstallable since i686 is not a compatible > architecture for i486. Architecture is checked first. Abi only when > required (like libs). > > > Your definition of ABI will provide different Application Binary > > Interfaces under the same name. > > ABI is only meaningfull when linking. That means libs, -dev, -dbg, > -pic packages. Installability of a package on its own comes first, abi > only when dealing with depends between packages. > > Thats how we see it currently.
That's a very debian-specific point of view. [snip] > > N32/N64 are way too different for a common label. Btw, there can also > > be ABI Variants (or subarchitectures, as you call it) for mips: > > > > MIPS I, MIPS II, MIPS III, MIPS IV, MIPS 64, MIPS 64R2 > > MIPS 32, MIPS 32R2 > > > > which aren't in a simple upward compatible chain (MIPS 32* is the > > odd one out). Further there are Application Specific Extensions (ASE) > > like MIPS 16, MDMX, MIPS 3D; similiar to MMX and SSE on ia32. > > Do you realy want to support any of those with a wider range of > packages? Probably, depending on demand and the actual performance gain. > If its just 2-20 packages its better to build them multiple > flavoured libs into one package and let ld choose the right one, like > the MMX optimized libs on i386. E.g. MIPS 16 allow very compact code, on low memory systems that's interesting for many packages. Thiemo
