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

Re: Multiarch support (was Moving 32-bit libraries to (/usr)/lib32on amd64)



Andreas Jochens a écrit :
Matthias Klose wrote:

Bdale Garbee writes:

On Fri, 2006-02-24 at 01:12 +0100, Aurelien Jarno wrote:


The only change planned is to make libc6-dev-i386 and libc6-i386 provide a glibc on amd64 instead of ia32-libs. It will be in /emul/ia32-linux (I still have to find how to do that cleanly in the debhelper files).

Bdale, do you agree with such a change?
Yes, I think we can handle that.  It means some small work on ia32-libs

to stop delivering any conflicting files, but I'm sure we can work that
out easily enough.  If you want to provide me a patch for ia32-libs that
does what you want it to do, that would be welcome.

thanks.  with this setup we are able to build our toolchain without
build dependencies on ia32-libs or with packages conflicting with
future multiarch packages (maybe additionally building lib32z1 from
zlib).


Hello,

please consider to install the 32-bit files from libc6(-dev)-i386, lib32gcc1, lib32stdc++ and lib32z1 in /usr/lib32 instead of /emul/ia32-linux/usr/lib.

This way the amd64 case would be handled in a similar way as the
other 32/64-bit "biarch" architectures.

IMHO, I think it would be better to use (/usr)/lib32. But I won't do any change without having a mail from Steve Langasek, Matthias Klose and Bdale Garbee telling that they are ok with this change.

I think that a future migration to multiarch will be easier if the amd64 case needs no special handling. Also, with /usr/lib32 there will be no need for ugly glibc debhelper file hacks as it would be for /emul/ia32-linux/usr/lib.

Here is my opinion:
Advantages
- Coherency between ports. MIPS will use /usr/lib32 when the tri-arch patch will be finished, the unofficial ppc64 pot uses /usr/lib32. Also this is the counterpart of /usr/lib64 on other arches. - Easier for biarch package maintainers, as they don't need to do special things for amd64. This is essentially true for the glibc. - /usr/lib32 is a search path for gcc /emul/ia32-linux/usr/lib is not, that's why we currently have a symlink.

Drawbacks:
- We have to change.

I suggest the following setup for 32-bit libraries on amd64:

1. The ia32-libs package continues to install the 32-bit libraries in /emul/ia32-linux/usr/lib but it stops to provide the 32-bit libc6(-dev) packages.

That was the plan.

2. The ia32-libs package does no longer provide a symlink from /usr/lib32 to /emul/ia32-linux/usr/lib.

Removing this link render the ia32-libs-dev package unusable as /emul/ia32-linux/usr/lib is not a search path when linking libraries.

3. The 32-bit libraries from libc6(-dev-)-i386, lib32gcc1, lib32stdc++, lib32z1 and other "_amd64.deb" packages are installed in /usr/lib32 which is not a symlink but a real directory.

Personally I feel we have to remove as much as possible libraries from ia32-libs replacing them by biarch packages, as it has been done for amd64-libs.

This package is not build from sources, but uses the binaries from i386.deb files. Yes the sources are also provided in the source package, but that doesn't really help more. Imagine you want to fix something, you can't simply apply a patch to ia32-libs sources and rebuild. That's bad, and at the limit of your policy manual.

Bdale, please don't take that as a personal attack. This package is really useful and also it exists! But I think we could do better.

4. The (/usr)/lib/i486-linux-gnu directories are reserved for future multiarch installations.


These changes could be implemented by simple patches without breaking
existing installations.

Yes, they are all on http://people.debian.org/~aurel32/amd64-lib32/ for a while.

Bye,
Aurelien

--
  .''`.  Aurelien Jarno	            | GPG: 1024D/F1BCDB73
 : :' :  Debian developer           | Electrical Engineer
 `. `'   aurel32@debian.org         | aurelien@aurel32.net
   `-    people.debian.org/~aurel32 | www.aurel32.net



Reply to: