David Wood <[EMAIL PROTECTED]> writes: > On Fri, 8 Jul 2005, Goswin von Brederlow wrote: > >> 3rd party software is nearly completly 32bit and our 32bit libs are >> already in the wrong place for rpath then. We can move >> /emul/ia32-libs/lib/* to /lib/i486-linux/ (same for usr/lib in all >> cases) without changing anything. >> >> We can also move /lib/* to /lib/x86_64-linux/* and adjust the /lib64 >> compatibility link without changing anything. That even works for >> rpath. >> >> We can even link /lib/i486-linux -> ., placing the 32bit libs in /lib >> to preserve rpath for both 32bit and 64bit. > > So, if I can go back to my original question: what are the blockers > for a package maintainer who wants to get started with multiarch? It > sounds like just some symlinks in base packages are all that need to > change...
and I repeat my answere: gcc, binutils, libtools, automake, autoconf. Toolchain issues. By all means move your lib around in your package and try them out. Recompile any rdepends your lib has. You will notice if something has problems. But I suggest not uploading those changes just yet. With all the transitions going on currently risking breakage you didn't test for would be bad. FYI: If I can convince the dpkg maintainer then I will add DEB_HOST_LIBDIR, DEB_HOST_LIB32DIR and DEB_HOST_LIB64DIR to dpkg-architecture. That way sources can use those variables to build and install their files already and when we decide the toolchain is all ready for multiarch dpkg-architecture changes the paths. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]