Hey everyone, please keep some perspective. It's just a name. It does not really need this much discussion. We just need to decide some name and stick for it. If we start discussing new naming policies now, there is going to be no end to the discussion, as it MOSTLY a matter of taste and everyone will likely just stick to their pet name.
On Thu, Mar 30, 2006 at 11:33:54AM +0200, Pjotr Kourzanov wrote: > >>Long and the dash ... =) > >That's what kfreebsd-i386, hurd-i386 etc have. > The difference being that those have OS-CPU scheme. > gnueabi-arm seems to be ABI-CPU scheme. If we are not going to reinvent the arch naming scheme, we need to stick the ABI somewhere, and OS is almost analogous to ABI. > >You are stuch with eabi-arm or gnueabi arm unless you are > >going to change the behaviour of dpkg-architecture while > >you are it :) > Why can't we just standardize on a single scheme and just implement that > in dpkg-architecture? I've already had to change it for arm-softfloat and > arm-vfp... We already have one, the one that is in dpkg-architecture. > My preference would be (OS-)CPU(-LIBC)(-ABI). The CPU might contain > additional > feature specs such as arm-softfloat or arm-vfp, allowing important > ARM combinations (arm, arm-softfloat, arm-uclibc, arm-gnuabi) as > well as stuff like hurd-i386 and kfreebsd-i386-uclibc. That would require > a list of known LIBC's as well as a list of known ABI's in addition of > the list known OS's and a list of known CPU's. If you or someone else implements a dpkg-architecture script with your naming scheme, we could use that. But notice that dpkg-architecture output is used in numerous scripts and debian/rules files, so arch renaming is going to be quite burdensom. Cheers, Riku -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
