-----BEGIN PGP SIGNED MESSAGE----- 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 <>< -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+lxq+5t5GS2LDRf4RAmHzAKCiqYgXZffN3cqtgF95aFd+rBVLHACfUjOH tje7TlhqQD5ySvSs6bNJwr0= =hmhD -----END PGP SIGNATURE-----