How does Portage handle accidental linkage? An issue I always find tricky to describe but I will try to explain:
If I have an install of Gentoo with 8000+ packages installed and try to build something like SDL2, Qt or Qemu this could well end up with a considerably different build compared to if I built the same software on a minimal Gentoo install (~20 packages).
This is because the CMake FindPackage, GNU autotools, et al for better or for worse tend to pull in random stuff dependending on what they find. Does portage have policies to avoid this (i.e building each package in a chroot with minimal dependencies)?
I like many parts of Gentoo (a standard *base*, a ports-like system, exotic platform support). Never gotten round to having a play with it though.
this is a very interesting thought experiment, and I understand your point. I cannot give you an authoritative answer, instead I will give you just a few pointers that I'm able to wrap my head around.
1. have a look at qemu's ebuild
here (this is basically a shell script that's equivalent to a port Makefile)
at line 61, defined as IUSE those are the USE flags that can be enabled/disabled for this package.
at line 501 - this is one of the functions that gets called during the configure stage of the package. all the states of those USE flags are built up in the conf_opts variable via the use_enable, conf_, usex functions.
so as you see most configure options get --enable-FOO --disable-FOO-ed explicitly when ./configure is run prior to compilation.
2. in Gentoo there is a script called revdep-rebuild that I use after every single update session. this scripts detects if there is any binary on the system that's dynamically linked against a missing library.
your scenario would eventually generate a hit if remotely compiled packages are being installed, a lib was picked up accidentally and the lib is not properly marked as a dependency in the ebuild. while I guess this might happen, I have never seen this corner case on my systems - and I actually actively look for this kind of breakage.
a simplified FreeBSD version of this script is here btw:
FreeBSD revdep-rebuild.sh , originally made for
this breakage
3. during (library) package removals portage checks if the .so file that should be removed from the filesystem is used by any binary. if the answer is yes then the package is marked as removed, but the .so is kept on the filesystem until the package containing the binary that still used that lib is removed.
4. portage uses a
sandbox to make sure that filesystem writes are limited to the build directory during the build process, but there is no special dependency-limiting chroot.
hope that helps, I never looked under the cover since python is not a language I understand.
