[just replying to bring this to the attention of the dpkg-maintainers.
At least Wichert does not read -devel. I hope that's alright.]
On Thu, Apr 10, 2003 at 10:12:25AM +0900, GOTO Masanori wrote:
> At Wed, 9 Apr 2003 23:08:31 +0200,
> Michael Banck wrote:
> > > Note that the x86_64 is special: It would be relatively easy to bootstrap
> > > a port on the actual hardware, but doing it right requires changing _all_
> > > library packages as well as many other packages. The problem is that
> > > we want binaries to be compatible with i386 as well as with other x86_64
> > > distributions and that requires the installation of both 32 and 64 bit
> > > libraries at the same time.
> >
> > FWIW, we can probably discuss how to do an x86-64 port in the right
> > way[tm] *NOW*, we don't need access the hardware for this.
>
> I fully agree.
>
> Moreover, this discussion is needed for architectures which can handle
> both 32bit and 64bit binaries for a long time. Currently glibc has
> already sparc64 and s390x port, but we will have x86_64, in addition
> probably ppc64 and mips64 (I have been interested in this area
> especially for maintaining glibc package).
>
> Currently only glibc and gcc has special handling for sparc64 and
> s390x. Almost all libraries are not concerned, so most applications
> on sparc64 and s390x are worked under 32bit. 32 bit is sufficient for
> almost personal users, but it's not for commercial use and probably
> future personal use (for handling large DVD/blueray movie data or so).
>
> I think generic 64bit libraries should put on {/lib64, /usr/lib64/,
> /usr/local/lib64, /usr/X11R6/lib64, ...}. Debian 64bit architecture
> packages should have only 64 bit libraries because it saves storage,
> and once we prepare 64bit port, we have no need to use 32bit
> binaries/libraries. To use 32 bit old libraries, dpkg and apt may
> be needed to modify handling both 32 bit and 64 bit packages like:
>
> apt-get install libgtk2.0-0(32) libgtk2.0-0
> dpkg -i libgtk2.0-0_ver_i386.deb libgtk2.0-0_ver_x8664.deb
>
> Well the version number "ver" should be same in 32/64 bit version.
> The above issue is only for generic libraries, and I have not
> considered how to handle glibc/gcc package yet.
>
> BTW, my concern about x86_64 issue is intel's 64bit extension (not
> ia64). If they plan to release 64 bit version i386, and it's
> different architecture from x86_64 (so XEAX is not existed, for
> example), we should not think that x86_64 is only 64 bit version of
> i386 (and i386 packages are shared between x86_64 and intel's i386
> 64bit).
