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

Re: Debian for x86-64 (AMD Opteron)



Hi,

On Thu, Apr 10, 2003 at 06:23:12PM +0200, Arnd Bergmann wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 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
> >
> > libssl0.9.6-0.9.6c-2_i386.deb or
> > libssl0.9.6-0.9.6c-2_i686.deb;
> >
> > on a x86-64 you'd have the choice between those same two plus
> >
> > libssl0.9.6-0.9.6c-2_x8664.deb
> 
> These two proposals have a significant difference. The first one
> needs more changes to the individual library packages because it
> changes not only the file names but also the package names. 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.

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.

> The second proposal would mean that dpkg will have to be changed
> so it can install the same package for both x8664 and {i386,i686}
> at the same time, which could prove difficult. The dependencies
> here can basically stay the same (e.g. ssh will continue to
> depend on libssl0.9.6 even on 64 bit), but dpkg and apt will have
> to know about an additional dimension concerning dependencies, e.g.:

That is exactly what Wichert wanted to avoid. I'm sorry, you probably
got this idea because of a most unfortunate typo of mine in the last
.deb I mentioned; I meant lib64ssl0.9.6-0.9.6c-2_x8664.deb there.

There are two distinct issues I wanted to illustrate:

1. different package name (for 64 bits), different architecture,
   more than one architecture allowed by dkpg: allows 32-bit and 64-bit
   versions of packages to coexist; allows (64-bit) machines to install
   packages from compatible (32-bit) architectures. This was Wichert's
   idea.

2. same package name, different "architecture", more than one
   architecture allowed by dpkg: solves CPU optimized libraries in
   a transparent way; no changes to dependencies necessary. This is what
   Wichert's suggested extension to dpkg would allow when using the same
   package name.

Hope it's clear now.

Cheers,


Emile.

-- 
E-Advies - Emile van Bergen           emile@e-advies.nl      
tel. +31 (0)70 3906153           http://www.e-advies.nl    

Attachment: pgp8siLXQKP6N.pgp
Description: PGP signature


Reply to: