Re: Debian cross infrastructure maintenance proposal
On 4/27/06, Pjotr Kourzanov <peter.kourzanov@xs4all.nl> wrote:
> Alexander Shishckin wrote:
>
> >On 4/27/06, Wookey <wookey@aleph1.co.uk> wrote:
> >
> >
> >>Yes. It is in the recently uploaded 2.16.1cvs20060413-1 so we can stop
> >>carrying that, and next try to push the -uclibc architectures in (althogh
> >>people need to agree which set of patches to push and the names (uclibc-i386
> >>or i386-uclibc for example - patches for both exist). This is part of the
> >>general 'arch-naming' debate we have been having. I'm not sure if a clib
> >>naming convention has been agreed?
> >>
> >>
> >binutils package has little to do with architecture naming, although,
> >I've never seen or heard of cross toolchains supporting this $cpu-$os
> >scheme. And honestly, I haven't seen even patches against dpkg to even
> >allow for such weirdness (and break compatibility with debian ports).
> >
> >
> Yes, it should remain $os-$cpu. Which brings up the question of why
> do you mix $os with $libc? Shouldn't uclibc-i386 then really be i386-uclibc
It has been several times discussed, and I'm strongly of this opinion
that $libc may well be considered $os. Don't differentiate between
them.
If you really want to bring up architecture topic, think of the good
'ol arm eabi, then think of softfloat vs hardfloat for different
architectures. But let's move this to another thread.
> (or, in full, linux-i386-uclibc)? How would you approach debianizing the
> following GNU_TYPE: arm-uclinux-uclibc, which IMHO could best be named
> uclinux-arm-uclibc?
Doesn't uclinux imply uclibc? (and who actually cares about uclinux here?)
Reply to: