Re: dpkg-architecture adaptations for e.g. uclibc and ABIs
Pjotr Kourzanov <peter.kourzanov@xs4all.nl> writes:
> Goswin von Brederlow wrote:
>> Pjotr Kourzanov <peter.kourzanov@xs4all.nl> writes:
>>
>>> Updated patch can be found here:
>>>
>>> http://www.xs4all.nl/~kurzanov/debian/patches/dpkg-1.13.16-all-1.patch.
>>>
>>> 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:
>
> linux-i386(-uclibc)?
> linux-arm(-uclibc)?(-eabi)?
> linux-mips(el)?(-[on]32|-n64)?
>
>>
>> MfG
>> Goswin
>>
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.
MfG
Goswin
Reply to: