(ack, might help to attach the bug first) An increasingly common problem we are seeing with some users is that they are constantly hosing python (and thus removing their ability to use portage) by unmerging libraries that python is linked again. root@kodiak blocke # ldd /usr/bin/python libdl.so.2 => /lib/libdl.so.2 (0x4002a000) libpthread.so.0 => /lib/libpthread.so.0 (0x4002d000) libutil.so.1 => /lib/libutil.so.1 (0x40042000) libtk8.3.so => /usr/lib/libtk8.3.so (0x40045000) libtcl8.3.so => /usr/lib/libtcl8.3.so (0x400fc000) libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x40186000) libdb-3.2.so => /usr/lib/libdb-3.2.so (0x4024e000) libz.so.1 => /usr/lib/libz.so.1 (0x402c3000) libm.so.6 => /lib/libm.so.6 (0x402d1000) libc.so.6 => /lib/libc.so.6 (0x402f3000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) If I were to say unmerge X, tk, tcl, or any other lib then I would be SOL and would have to dig around for either a tbz2 of python without that library support or look for the cd... Unmerging X or tk/tcl should not hose a users install because they forgot to recompile a scripting language interpreter first :) Maybe we need a dual python binary install?
This is a Portage2 thang. Forwarding to portage2-dev
This has now been fixed in python-2.2-r6. We now build .so's for all those modules instead of linking them in statically. This also reduces the python2.2 footprint. Unmerging tcl/tk, xfree86 and even db-3 and zlib (!) should be safe.
