On Wed, Dec 15, 2010 at 6:06 AM, justin <j...@gentoo.org> wrote: > Hi, > > after testing this, and I have to say it mostly works smooth and fine, I > hit a huge problem. > > I wanted to emerge a package which just depends on glibc provided libs > for the oposite ABI my main ABI is. This specific package has an > optional support for python which would require to have a second python > installation, so I disabled it. Nevertheless the package inherits the > python.eclass which DEPENDS on eselect-python, which DEPENDS on python. > Resulting in the need of a two ABI python installation although I don't > want python support. > > To solve this there are two options: > > 1. Eclasses shouldn't be allowed to depend unconditionally on packages. > In case of python where there is PYTHON_DEPEND="python? X" it should be > doable. > 2. USE dependend inherit of eclasses > > > justin
I played with the multilib overlay today and hit a similar problem. Say I want to install 32-bit Mesa, so that I can better control what's installed compared to app-emulation/emul-linux-x86-opengl. I set per-package USE of multilib_abi_amd64 multilib_abi_x86 for mesa. Clearly it makes sense that 32-bit mesa would require 32-bit x11 libraries and other runtime-dependencies, but with the current multilib-portage it also requires things that are totally ABI-independent like dri2proto to be reinstalled with MULTILIB_ABI="amd64 x86". This extends to all packages eventually, so gcc, binutils, and glibc (which are already totally capable of producing or supporting 32-bit x86 code as-is) need to be reinstalled with new MULTILIB_ABI flags. Other helper programs like autoconf and automake have to be reinstalled with MULTILIB_ABI="amd64 x86" just to be able to support 32-bit mesa, even though a 64-bit automake would work just fine. For this problem, I think some kind of per-ebuild ABI_DEPENDENT flag should be used to recognize which packages ABI dependencies should apply to. Without thinking about it too hard, it seems like perhaps only packages in RDEPEND should be considered for ABI USE dependencies. Comments? It'd be great to get some more man-power behind this project. I think almost everyone wants to see the emul- packages replaced by something more flexible, and architectures that support multiple ABIs like ARM and MIPS would benefit greatly as well. Matt
