Re: dpkg-architecture adaptations for e.g. uclibc and ABIs
Pjotr Kourzanov <firstname.lastname@example.org> writes:
> Goswin von Brederlow wrote:
>> Pjotr Kourzanov <email@example.com> writes:
>>> Updated patch can be found here:
>>> Besides allowing CPU-uclibc architectures it also adds:
>>> 1. Specific ARM families armv4,armv5te,strongarm and xscale
>>> 2. ARM variations such as VFP and softfloat (old ABI)
>>> 3. EABI suffix for linux, linux-uclibc, hurd and hurd-uclibc
>>> (last two are rather fictional though;-)
>> What about mips O32, N32 and N64 ABIs? Can they be differentiated with
>> that method too?
> Yes, I suppose they could. What I did for arm-eabi before armel was chosen
> is to add linux-eabi and linux-uclibc-eabi to ostable. The rest comes sort
> of automatically because of (.*) in split_debian from dpkg-architecture.
> We do need a way still to prohibit certain combinations (eabi for MIPS,
> O32, N32 and N64 for ARM)... Maybe an abitable besides ostable and cputable
> would suffice with content such as:
With multiarch that solves itself. Every ABI is its own architecture
and dpkg/apt will (somehow, automatic? conffile? something anyway)
know what architectures the cpu can run.