RE: amd64 and dpkg and so
I need to clarify my question a little more, I think...
Other Linux distributions have gone the route of a 64-bit distribution with support of 32-bit binaries. So all dependencies assume 64-bit versions of packages, and just about everything is recompiled for AMD64. They also install 32-bit packages on the same system which provide the needed 32-bit infrastructure. Even closed-source third party 32-bit packages should be agreeable to that; they'll seek out the 32-bit dependency packages anyway.
So what you would have is two sets of packages installed... your primary one being the 64-bit packages, and you would have some minimal set of 32-bit library packages installed on the same system to support running 32-bit binaries.
What I think you're trying to do now is to allow 64-bit packages to depend on 32-bit ones where a 64-bit version of the dependency isn't really necessarily. The example of the 64-bit /bin/ls, for example. Not really necessary, but then again, the only difference between 32-bit /bin/ls and 64-bit /bin/ls is really a minimal increase in code size. Rather than "why port it?" I would ask, "why not?" Make 64-bit packages depend on 64-bit packages and leave 32-bit packages dependent on 32-bit packages.
Maybe I'm being overly simplistic about this... you tell me.
-----Original Message-----
From: Martin Jungowski [mailto:jungowsk@in.tum.de]
Sent: Thursday, August 28, 2003 3:47 AM
To: debian-x86-64@lists.debian.org
Subject: Re: amd64 and dpkg and so
That is so true. The CPU is capable of running 32-bit software in 64-bit
mode as fast as in native 32-bit mode - whatever you do, you HAVE to be
able to run standard 32-bit software otherwise nobody's going to use the
64-bit Linux.
Mind you, not everything is available as 64-bit port yet and not
everything will be available as 64-bit port for a long time.
So yes, you're absolutely right. Not being able to run 32-bit software
in 64-bit mode is not very clever however given the CPU, I don't think
it's possible to restrict a 64-bit distro like that - how would you even
want to do that, the kernel and all the libs and everything can be
64-bit so the CPU is going to run in Long Mode (that's what AMD named
the 64-bit mode) but any 32-bit code will still run, I don't see a way
to stop it from running
Martin
On Thu, 2003-08-28 at 12:20, Roland Fehrenbacher wrote:
> >>>>> "Martin" == Martin Jungowski <jungowsk@in.tum.de> writes:
>
> Martin> On Thu, 2003-08-28 at 10:43, Roland Fehrenbacher wrote:
> >> Fully agreed. A pure 64bit distro would be nothing more than an
> >> academical exercise at this stage and the foreseeable future with little
> >> practical value and even less real users. 32 bit binaries will need to
> >> run on these machines for a long time. Please don't waist resources for
> >> this.
>
> Martin> Oh I don't think so. The AMD Opteron is a lot faster in 64-bit than
> Martin> in 32-bit. Not only does it have eight additional GPRs but also the
> Martin> XMM-Registers (aka SSE). During my benching, every single 64-bit
> Martin> test was faster than the same software compiled for 32-bit -
> Martin> sometimes more than 20% faster in 64-bit
>
> I fully agree with what you say about the Opteron. But it doesn't contradict
> what I said. Every user of such a system will more than likely also need or
> want to run a 32bit binary on such a machine at some stage, and it is just too
> restrictive not to be able to do that. It is clear that you want to run 64bit
> whenever you can, but you won't always be able to.
>
>
--
To UNSUBSCRIBE, email to debian-x86-64-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: