[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Debian for x86-64 (AMD Opteron)

Hash: SHA1

On Friday 11 April 2003 15:49, Emile van Bergen wrote:
> On Thu, Apr 10, 2003 at 06:23:12PM +0200, Arnd Bergmann wrote:
> > On Thursday 10 April 2003 16:43, Emile van Bergen wrote:
> > > On Thu, Apr 10, 2003 at 03:33:39PM +0200, Wichert Akkerman wrote:
> > > > # echo x86-64 >> /etc/dpkg/legal-archs
> > > > # dpkg -i libgtk2-2.0-1_i386.deb
> > > > # dpkg -i lib64gtk2-2.0-1_x8664.deb
> > I'm not sure how to best handle dependencies on this.
> Simple: explicitly. I don't think it'd be a good idea to allow 32-bit
> apps to link to 64-bit libraries and vice versa. How would you layout
> the (shared) address space? Handling all cases would become a mess
> quickly.
Right. In case it was not clear to everybody: The ELF format does not 
specify linking of 32 and 64 objects together, so this is not subject
to discussion anyway.

> You do want to allow both 32-bit and 64-bit versions of libraries to be
> installed, for which you need different package names; you want to avoid
> adding fields to a package's "primary key", so that the dependency tree
> assmebly mechanisms can be left as they are.
Yes, but what I also want to avoid is having to change every single instance
of 'Depends: libfoo' to 'Depends: libfoo [! x86_64, sparc64, s390x, ppc64,
hppa64], lib64foo [x86_64, sparc64, s390x, ppc64, hppa64]' and then changing
them all again for mips64 ;-).

What I have in mind is something along the lines of
 libfoo   'Provides: libfoo(32bit)'
 lib64foo 'Provides: libfoo(64bit)'
 bar      'Depends: libfoo($BITSIZE)'
I don't know if it's possible to teach dpkg and the other tools about this.
And this is only the tip of the iceberg: As  Cyrille noted already, the
real challenge will be finding a policy for the -dev packages.

	Arnd <><
Version: GnuPG v1.2.1 (GNU/Linux)


Reply to: