How to handle multiarch on x86-64. Problem: We want to be able to install libfoo built for i386 and libfoo built for amd64 at the same time. The reason we want this is that we want to be able to install applications linking against both the 32 bit and 64 bit libraries. Solution: lib64foo, libfoo, libfoo-dev. lib64foo is arch: amd64, libfoo is arch: i386. libfoo-dev is arch: any, so you can't install both libfoo-dev built for i386 and libfoo-dev built for amd64 at one time. This is a tradeoff making it still possible to build packages for a different subarchitecture, but keeping things as simple as possible. dpkg-checkbuilddeps should check that the build-deps are of the same subarchitecture as the build will be for. This is to avoid having a package "example-pkg" Build-Depending on libfoo-dev and libbar-dev (Build-Depends: libfoo-dev, libbar-dev) and having those installed with differing architectures, which will obviously create havoc. Questions: Q: Why not lib64foo-dev? A: Why have lib64foo-dev? If it should be co-installable with libfoo-dev, they will both have to depend on a common package libfoo-dev-common which will include such directories as /usr/include and /usr/share/doc/libfoo-dev-common (with /usr/share/doc/libfoo-dev and /usr/share/doc/lib64foo-dev being symlinks to said directory). This will increase the number of packages in the archive fairly much (about 600). It will also require changes to between 400 and 800 source packages (manual tuning of Depends field) and about 200 more source packages (for versioned Build-Depends). Q: What about other programs using /usr/lib/*, plugins and so on? A: They will have to have a Depends field somewhat like (example for i386 apache) Depends: apache-common [i386], or (example for amd64 apache) Depends: apache-common [amd64]. Of course, this should be handled fairly transparently through dpkg substvars of some kind. You can not load 32 bit from 64 bit programs and vice versa, at least not without doing heavy magic. This means that a 64 bit gimp need 64 bit gimp modules, 64 bit apache needs 64 bit apache modules, 64 bit apache-perl needs 64 bit apache, and so on. Q: How will binary {perl,apache,etc} modules be handled? A: Currently, there are no plans, which means that you can either have 32 bit or 64 bit installed, not both. Each language/program will of course be free to provide any solution they feel like. We are trying to solve the problem of normal shared libraries first. Suggestions are of course welcome. Most applications shouldn't need to coexist in 32 and 64 bit forms, so it won't be a problem for them. They just need to depend on the right libraries for the right architecture. Q: Is the [$arch] syntax handled for Depends fields today? A: No, not today, but patches for handling it are on the way, for both dpkg and apt. The archive tools (katie) will most likely also have to be changed. Comments/suggestions should be sent to Tollef Fog Heen