Hi there, I'll start a separate thread to avoid polluting the "soft-dep" thread. A number of people seem to have rather strong feelings against multilib, however i get the impression that the impact is in fact not that big. To help us with deciding, here's a summary of what I think would be a good approach: 1. core-x86_64/{glibc,gcc,binutils,bin86} multilib 2. all the rest of core-x86_64 and opt-x86_64 is pure 64-bit 3. we offer separate compat32 repositories (as compat32.rsync.inactive), For the pure 64 user, the only drawback is the additional 32-bit binaries for glibc, gcc and binutils. At the same time, the user has the option to add the 32-bit compatibility layer should the need arise later on, without the need to replace glibc/gcc on the running system. - there's no performance penalty - there's no additional issues (since compat32 is purely optional) which can happen on such a system that wouldn't on a absolutely pure64 one - there are no workarounds/hack required in Pkgfiles, pkgutils or pkgmk.conf For us developers, it means that with a single platform, we can cover both groups of use(r)s. Those that care about compat32 can join as maintainer in these repos as well, - there's no additional work involved, we have to maintain gcc et al anyway, and helping in compat32 is optional So to me, it boils down to this: - some disk space "wasted" when running only 64-bit binaries + chance to add the compat32 layer at any point without any hassle + single platform, which means all development efforts, bug solutions etc. help both the "pure" and "non-pure" users. Anything I missed? Thanks for reading, Johannes -- Johannes Winkelmann mailto:jw@smts.ch Zurich, Switzerland http://jw.smts.ch