Re: not pending anymore
ebiederm@xmission.com (Eric W. Biederman) writes:
> Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de> writes:
>
>> Hi,
>>
>> you seem to be one more voice falling into the
>>
>> "I don't like the name Amd wants us to use but I have nothing better"
>
> That is not what I said.
>
>> group. If you can't suggest a workable alternative to amd64 thats
>> meaningless.
>
> Ok I will x86-64. That is what recent dpkg patch used
We believe there are sources that won't build correctly with
that. Some sources use the deb arch instead of gnu cpu and would end
up passing something like x86-64-linux to the configure script, which
would match x86-*-linux and build 32bit debs. We have fixed a few such
(and similar) cases already that resulted in build-failures and we
don't know how many more there are.
Even bigger problems happen with sources/tools that assume - is the
seperator between cpu and os as in i386-hurd. Splitting those with
x86-64 in the mix would be made more difficult.
Its also very confusing to have x86-64 (deb arch) and x86_64 (gnu cpu)
apear side by side. Either have them identical (x86_64) or clearly
distinct (amd64 / x86_64) and identical has the _ problem.
For all those reasons I strongly dislike x86-64 and don't consider it
workable. Too much would have to be fixed.
> and I have successfully built packages with that name. Getting that
> to work was mostly a matter of removing a couple of artificial
> restrictions, in some of the tools. Using x86_64 is more problematic
> in that a lot of debian naming conventions assume a special meaning
> for underscore.
>
>> Neither x86-64 nor x86_64 are workable with the tools at
>> hand and a dislike for marketing guys is absolutely no reason for us
>> to change the name to something else.
>
> This is not a dislike for marketing guys. I do not think technical
> decisions should be made to try and match a marketing name. Marketing
> names continually change. So I think it would potentially be a never
> ending struggle to keep all packages with the current marketing
> name.
Once the name is set its not going to change. So there is no keeping
up that needs to be done.
> Beyond that I suggested that amd64 be an official alias. So packages
> named x86-64 and amd64 both map to the x86-64 architecture.
Thats not possible with the current design. Its trivial with multiarch
though.
> So what I was really suggesting was to use both, and to normalize on
> x86-64. I was hoping that was a sane enough suggestion that people
> could adopt it and move on with life.
x86-64 would be neigther what the toolchain uses nor what people
use. The - was only choosen in dpkg as workaround for _ and I fail to
see the reason to use a problematic workaround when we have perfectly
functioning name already (amd64). x86-64 is an invention of the dpkg
maintainer.
You might also want to read up on the discussion and decision taken
last year that resulted in moving away from x86_64 and to amd64.
> Now I have not done a lot of packaging with debs and that appears to
> be where my confusion comes from. When messing with rpms frequently
> there are .i386 and .i686 rpms depending on how they are optimized
> and the both are fundamentally the same architecture. In this area
> debs appear to be much less flexible so I guess you must choose
> exactly one or rework the tools. In that case go with amd64,
> it is not the most beautiful but the debian tools work without
> modification.
>
> Eric
Thats something that multiarch will give us for free. With mutliarch
dpkg detects that you have an i686 and will allow deb packages for
i686, i586, i486, i386 to be installable. We will have to wait for
multiarch to get a clean support for optimized packages.
Without multiarch all packages will be named i386 and optimized libs
get their name mangled like libc6-i686 and are still _i386.deb.
MfG
Goswin
Reply to: