Both dev-python/astng-0.17.0 and dev-python/logilab-common-0.21.2 own the file /usr/lib/python2.4/site-packages/logilab/__init__.py astng and logilab-common were were brought in as dependencies when I emerged dev-python/pylint-0.13.1, and the file collision error came up for the mentioned file. Steps to reproduce: # emerge dev-python/logilab-common dev-python/astng Additional information: $ equery belongs /usr/lib/python2.4/site-packages/logilab/__init__.py [ Searching for file(s) /usr/lib/python2.4/site-packages/logilab/__init__.py in *... ] dev-python/astng-0.17.0 (/usr/lib/python2.4/site-packages/logilab/__init__.py) dev-python/logilab-common-0.21.2 (/usr/lib/python2.4/site-packages/logilab/__init__.py) $ equery check astng [ Checking dev-python/astng-0.17.0 ] * 62 out of 62 files good $ equery check logilab-common [ Checking dev-python/logilab-common-0.21.2 ] !!! /usr/lib/python2.4/site-packages/logilab/__init__.py has wrong mtime (is 1211333189, should be 1211333156) * 100 out of 101 files good $ cat /usr/lib/python2.4/site-packages/logilab/__init__.py """generated file, don't modify or your data will be lost""" $ md5sum /usr/lib/python2.4/site-packages/logilab/__init__.py b2eb32833687ea1fc6a89205b5b2f356 /usr/lib/python2.4/site-packages/logilab/__init__.py $ grep /usr/lib/python2.4/site-packages/logilab/__init__.py /var/db/pkg/dev-python/{astng-0.17.0,logilab-common-0.21.2}/CONTENTS /var/db/pkg/dev-python/astng-0.17.0/CONTENTS:obj /usr/lib/python2.4/site-packages/logilab/__init__.py b2eb32833687ea1fc6a89205b5b2f356 1211333189 /var/db/pkg/dev-python/logilab-common-0.21.2/CONTENTS:obj /usr/lib/python2.4/site-packages/logilab/__init__.py b2eb32833687ea1fc6a89205b5b2f356 1211333156 As can be seen above, the file contents are the same for both ebuilds. $ emerge --info Portage 2.1.4.4 (default-linux/amd64/2007.0/desktop, gcc-4.1.2, glibc-2.6.1-r0, 2.6.24-gentoo-r4 x86_64) ================================================================= System uname: 2.6.24-gentoo-r4 x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 5200+ Timestamp of tree: Tue, 20 May 2008 21:15:02 +0000 app-shells/bash: 3.2_p33 dev-java/java-config: 1.3.7, 2.1.6 dev-lang/python: 2.4.4-r9 dev-python/pycrypto: 2.0.1-r6 sys-apps/baselayout: 1.12.11.1 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.13, 2.61-r1 sys-devel/automake: 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10.1 sys-devel/binutils: 2.18-r1 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 1.5.26 virtual/os-headers: 2.6.23-r3 ACCEPT_KEYWORDS="amd64" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -march=k8 -mfpmath=sse -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/config" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c /etc/udev/rules.d" CXXFLAGS="-O2 -march=k8 -mfpmath=sse -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="distlocks metadata-transfer parallel-fetch sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="http://darkstar.ist.utl.pt/gentoo/ http://cesium.di.uminho.pt/pub/gentoo/ ftp://cesium.di.uminho.pt/pub/gentoo/ http://ftp.dei.uc.pt/pub/linux/gentoo/ ftp://ftp.dei.uc.pt/pub/linux/gentoo/ http://linuv.uv.es/mirror/gentoo/ ftp://darkstar.ist.utl.pt/pub/gentoo/" LANG="en_US" LINGUAS="en" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="3dnow 3dnowext X a52 aac aalib acl acpi adns akode alsa amd64 amr amrnb amrwb arts bash-completion berkdb bzip2 cairo cdda cddb cdparanoia cdr cli clisp cracklib crypt cscope css cups curl dbus dia djvu dri dts dv dvd dvdr dvdread dvi eds emboss encode esd evo exif expat fam fame ffmpeg fftw firefox flac fortran fpx gd gdbm gif gimp gimpprint glib glitz gphoto2 gpm graphviz gs gstreamer gtk gtkhtml hal hdri iconv id3tag idea ieee1394 imagemagick imlib inkjar ipv6 isdnlog jbig jpeg jpeg2k kde kdeenablefinal kdehiddenvisibility kqemu libcaca libnotify libsamplerate lm_sensors log4j logrotate lzo mad matroska midi mikmod mjpeg mmx mmxext mng motif mp2 mp3 mpeg mudflap musepack ncurses new-clx nls nptl nptlonly nvidia ogg oggvorbis openexr opengl openmp oss pam pch pcre pda pdf perl pg-intdatetime plotutils png pnm portaudio postgres postscript ppds pppd python qt qt3 qt3support qt4 quicktime rar readline reflection scanner sdl session silc smp sndfile solver soundtouch speex spell spl sqlite sqlite3 srt sse sse2 ssl startup-notification svg t1lib tcpd tetex theora threads tiff timidity truetype tta twolame unicode usb v4l2 vamp vcd vim-syntax vorbis wavpack wma wmf x264 xanim xattr xml xorg xpm xv xvid xvmc zlib zoran" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="evdev keyboard mouse wacom" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en" USERLAND="GNU" VIDEO_CARDS="nv nvidia vesa" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, LDFLAGS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY
Duplicate of bug #111970 (which is fixed for more than two years already)... Thus I can't reproduce the bug ;) From astng-0.17.[02].ebuild: # we need to remove this file because it collides with the one # from logilab-common (which we depend on). rm "${D}/usr/$(get_libdir)/python${PYVER}/site-packages/logilab/__init__.py"
Well, if the problem was fixed, it seems to have been an incomplete fix or there's been a regression, because the file is still being replaced on the filesystem... # emerge -1 dev-python/logilab-common dev-python/astng | grep /usr/lib/python2.4/site-packages/logilab/__init__.py >>> /usr/lib/python2.4/site-packages/logilab/__init__.py --- replaced obj /usr/lib/python2.4/site-packages/logilab/__init__.py >>> /usr/lib/python2.4/site-packages/logilab/__init__.py --- replaced obj /usr/lib/python2.4/site-packages/logilab/__init__.py Note the local file is being replaced twice (once by logilab-common and again by astng). It's easy to verify that the file's timestamp changes when you install astng over logilab-common: # emerge -1 dev-python/logilab-common # date -r /usr/lib/python2.4/site-packages/logilab/__init__.py Sat Jul 12 01:16:31 WEST 2008 # emerge -1 dev-python/astng # date -r /usr/lib/python2.4/site-packages/logilab/__init__.py Sat Jul 12 01:17:12 WEST 2008 The conflict is therefore still there, and it is breaking the consistency checks: # equery check dev-python/logilab-common [ Checking dev-python/logilab-common-0.21.2 ] !!! /usr/lib/python2.4/site-packages/logilab/__init__.py has wrong mtime (is 1215821353, should be 1215821346) * 100 out of 101 files good rex ~ # equery check dev-python/astng [ Checking dev-python/astng-0.17.0 ] * 62 out of 62 files good astng replaced the file, so logilab-common (which was installed first) sees the wrong modification time and complains that the file is broken.
# emerge -1av logilab-common \=astng-0.17.0 && equery check logilab-common [...] [ Checking dev-python/logilab-common-0.21.2 ] * 102 out of 102 files good Perhaps it's a python-2.4-only error ... *checking* When have you synced your tree the last time?
Hmm ... the problem seems to be, that your python packages are installed to /usr/lib/python2.4 ... and the ebuild tries to remove from /usr/$(get_libdir)/python2.4 - where get_libdir should resolve to lib64
(In reply to comment #3) > When have you synced your tree the last time? July 10th, problem still exists. (In reply to comment #4) > Hmm ... the problem seems to be, that your python packages are installed to > /usr/lib/python2.4 ... and the ebuild tries to remove from > /usr/$(get_libdir)/python2.4 - where get_libdir should resolve to lib64 > You found the problem! I just looked at the emerge output and the rm is failing: rm: cannot remove `/var/tmp/portage/dev-python/astng-0.17.0/image//usr/lib64/python2.4/site-packages/logilab/__init__.py': No such file or directory A look at the temporary install directory shows us that the installation directory is actually lib: # ls /var/tmp/portage/dev-python/astng-0.17.0/image//usr/ lib/ share/ The ebuild is trying to remove from lib64, when it should be trying to remove from lib. The thing is, on amd64 systems, /usr/lib and /lib are really just symlinks: # file /lib /usr/lib /lib: symbolic link to `lib64' /usr/lib: symbolic link to `lib64' I take it your system isn't amd64, thus your get_libdir returns lib instead of lib64 like it does for me. I wonder if other ebuilds are also using get_libdir and silently causing problems on systems where get_libdir returns something but what actually exists in the temporary directories ($D, $WORKDIR, etc) is something else...
The question is: Why are your python packages installed into lib? - Asking another amd64 user, he told me, that they are installed into lib64 for him... (And this is also what I remembered...)
(In reply to comment #6) > The question is: Why are your python packages installed into lib? - Asking > another amd64 user, he told me, that they are installed into lib64 for him... > (And this is also what I remembered...) > It's happening for some ebuilds, but not all: $ equery files dev-python/PyQt4 | grep -c /lib/ 0 $ equery files dev-python/PyQt4 | grep -c /lib64/ 50 whereas: $ equery files dev-python/astng | grep -c /lib/ 54 $ equery files dev-python/astng | grep -c /lib64/ 0 Broken ebuilds would be my first guess (e.g. not configuring the source code's installer to install to a different prefix). Could you please ask your amd64 friend to try the following: # emerge -1va dev-python/astng # grep -c /lib/ /var/db/pkg/dev-python/astng-0.17.0/CONTENTS # grep -c /lib64/ /var/db/pkg/dev-python/astng-0.17.0/CONTENTS So we can see whether or not astng is installing on /lib/ for him?
dev-python/django-0.96.2 for example also installs its files on lib: $ equery files django | grep -c /usr/lib/ 711 However, it also touches lib64: $ equery files django | grep /usr/lib64/ /usr/lib64/python2.4 /usr/lib64/python2.4/site-packages From the ebuild we can clearly see why the lib64 directory itself gets touched, but apparently nothing else is being done to tell the source it should install to lib64: src_install() { distutils_python_version site_pkgs="/usr/$(get_libdir)/python${PYVER}/site-packages/" export PYTHONPATH="${PYTHONPATH}:${D}/${site_pkgs}" dodir ${site_pkgs} [...] Being as though /usr/lib is a symlink to /usr/lib64, in practice things "just work" regardless of whether the ebuilds do The Right Thing. However, for package management purposes (such as file conflicts and such) some (how many?) ebuilds seem to be doing the wrong thing.
(In reply to comment #7) > Could you please ask your amd64 friend to try the following: > > # emerge -1va dev-python/astng > # grep -c /lib/ /var/db/pkg/dev-python/astng-0.17.0/CONTENTS > # grep -c /lib64/ /var/db/pkg/dev-python/astng-0.17.0/CONTENTS > > So we can see whether or not astng is installing on /lib/ for him? # grep -c /lib/ /var/db/pkg/dev-python/astng-0.17.2/CONTENTS 0 # grep -c /lib64/ /var/db/pkg/dev-python/astng-0.17.2/CONTENTS 54
(In reply to comment #9) > # grep -c /lib/ /var/db/pkg/dev-python/astng-0.17.2/CONTENTS > 0 > > # grep -c /lib64/ /var/db/pkg/dev-python/astng-0.17.2/CONTENTS > 54 Hmm so there is a discrepancy here, that's strange... I've done some researching into the ebuild installation process and the Python distribution utilities, and I am getting the increasing impression that my system installing this package to lib is the expected "Pythonic" behavior - the package contains no platform-specific modules, it is all pure Python (see below for more). Doing the merge steps manually, after an ebuild .../astng-0.17.0.ebuild compile, the $WORKDIR/$P directory contains lib/logilab/astng/ with all the .py files to be installed there. So far everything looks normal. After an ebuild .../astng-0.17.0.ebuild install, the $D directory contains usr/, which contains: # ls usr lib/ share/ Evidently the difference to your friend's system is somewhere before this step. Now, repeating the ebuild install phase with --debug, I noticed the following: [...] + distutils_src_install ++ python -c 'from distutils.sysconfig import get_python_lib; print get_python_lib()' + pylibdir=/usr/lib/python2.4/site-packages + '[' -n /usr/lib/python2.4/site-packages ']' + dodir /usr/lib/python2.4/site-packages [...] And here begin the differences. This is being run by the ebuild's src_install() function: src_install() { distutils_src_install python_version [...] The distutils_src_install function is in /usr/portage/eclass/distutils.eclass and begins with: distutils_src_install() { # need this for python-2.5 + setuptools in cases where # a package uses distutils but does not install anything # in site-packages. (eg. dev-java/java-config-2.x) # - liquidx (14/08/2006) pylibdir="$(${python} -c 'from distutils.sysconfig import get_python_lib; print get_python_lib()')" [ -n "${pylibdir}" ] && dodir "${pylibdir}" if has_version ">=dev-lang/python-2.3"; then ${python} setup.py install --root=${D} --no-compile "$@" || die Now, my distutils.sysconfig.get_python_lib() returns "/usr/lib/python2.4/site-packages", which causes the above dodir to touch that directory. This in itself doesn't alter the location where the files are installed, but it is curious that in your friends case it seemingly touches on lib64 instead. If we look at /usr/lib64/python2.4/distutils/sysconfig.py, we've got: def get_python_lib(plat_specific=0, standard_lib=0, prefix=None): [...] if os.name == "posix": if plat_specific: lib = "lib64" else: lib = "lib" From the function's documentation: If 'plat_specific' is true, return the directory containing platform-specific modules, i.e. any module from a non-pure-Python module distribution; otherwise, return the platform-shared library directory. What I'm seeing on my system really seems to me like expected, documented behavior... The astng package's .py files are being installed on the platform-shared library directory, /usr/lib/python2.4 and that makes sense to me because they're really only .py files and should be platform independent. What does your friend's amd64 system print with the following command? $ python -c 'from distutils.sysconfig import get_python_lib; print get_python_lib()' My system prints /usr/lib/python2.4/site-packages, as noted above. I take it his system would print /usr/lib64/python2.4/site-packages ? This is all still regarding the touching of /usr/lib/python2.4/site-packages, though. Regarding the actual files, they are installed through the normal Python distutils process, by the $WORKDIR/$P/setup.py script, which gets called by distutils_src_install() above. The destination of the files is determined by the Python distutils install_lib command, which in turn gets it from the install command in distutils.command.install_lib.finalize_options(): self.set_undefined_options('install', ('build_lib', 'build_dir'), ('install_lib', 'install_dir'), ('force', 'force'), ('compile', 'compile'), ('optimize', 'optimize'), ('skip_build', 'skip_build'), What this is doing is initializing the install_dir attribute (among others) from the install command's install_lib attribute. And, since this package doesn't contain any non-pure-py modules, install_lib is set to $D/usr/lib/python2.4/site-packages. From /usr/lib64/python2.4/distutils/command/install.py: # Pick the actual directory to install all modules to: either # install_purelib or install_platlib, depending on whether this # module distribution is pure or not. Of course, if the user # already specified install_lib, use their selection. if self.install_lib is None: if self.distribution.ext_modules: # has extensions: non-pure self.install_lib = self.install_platlib else: self.install_lib = self.install_purelib install_purelib is the "/lib/" version, install_platlib is the "/lib64/" version. purelib is being selected, and that propagates to install.install_lib, which propagates to install_lib.install_dir, which controls where the .py files are installed. This all makes sense to me, given the documentation in the .py source. What's happening on my system seems to me to be the "Pythonic" way: platform-specific stuff gets installed to /lib64/, pure Python stuff gets installed on /lib/. What I don't understand is why astng is being installed on lib64 on your friend's system. Could you please get your friend to run the following to compare the paths? $ python -c 'from distutils.command.install import install; \ from distutils.dist import Distribution; x = install(Distribution()); \ x.finalize_options(); print "purelib:", x.install_purelib; \ print "platlib:", x.install_platlib; print "install_lib:", \ x.install_lib' On my system, this would print: purelib: /usr/lib/python2.4/site-packages platlib: /usr/lib64/python2.4/site-packages install_lib: /usr/lib/python2.4/site-packages/ Thank you!
(In reply to comment #10) > Could you please get your friend to run the following to compare the paths? > > $ python -c 'from distutils.command.install import install; \ > from distutils.dist import Distribution; x = install(Distribution()); \ > x.finalize_options(); print "purelib:", x.install_purelib; \ > print "platlib:", x.install_platlib; print "install_lib:", \ > x.install_lib' > > On my system, this would print: > purelib: /usr/lib/python2.4/site-packages > platlib: /usr/lib64/python2.4/site-packages > install_lib: /usr/lib/python2.4/site-packages/ purelib: /usr/lib64/python2.5/site-packages platlib: /usr/lib64/python2.5/site-packages install_lib: /usr/lib64/python2.5/site-packages/ Perhaps the handling changed in python2.5 - don't know. Perhaps it changed somewhen later in Gentoo for python in general... you could try to re-install python2.4 and see if this changes anything. But - I think this really needs some attention from the official Gentoo-Python team. All the lib/lib64 stuff needs to be clarified (there are python packages installing to /usr/lib - and others to /usr/$(get_libdir)).
Is this also a blocker for bug #232575?
(In reply to comment #12) > Is this also a blocker for bug #232575? > Well, I would really like to hear from the Gentoo-Python team regarding the whole lib/lib64 thing... Right now I'm not even sure what the packages should be doing. From what I read in the Python distutils comments it would seem that /usr/lib should be used for pure Python modules, and /usr/$(get_libdir) should be used for platform-specific stuff (i.e. .so modules and so on). The existence of bug #232575 suggests that my thinking above is wrong, though, and that packages should all just drop their modules on /usr/$(get_libdir). If that's the case then yes, I would say this bug should be added to that tracker. It would sure be nice to hear something definitive from Gentoo-Python, though.
I can't reproduce this bug with dev-python/astng-0.19.0 and dev-python/logilab-common-0.43.0.
I can reproduce this bug with USE_PYTHON="2.4 2.6" and amd64 platform. python_get_sitedir is the root function called by the ebuild which is failing. Portage 2.1.9.25 (default/linux/amd64/10.0, gcc-4.4.4, glibc-2.11.2-r3, 2.6.36-gentoo-r5 x86_64) ================================================================= System uname: Linux-2.6.36-gentoo-r5-x86_64-QEMU_Virtual_CPU_version_0.12.5-with-gentoo-1.12.14 Timestamp of tree: Mon, 07 Feb 2011 22:00:01 +0000 app-shells/bash: 4.1_p9 dev-java/java-config: 2.1.11-r3 dev-lang/python: 2.4.6, 2.6.6-r1, 3.1.2-r4 sys-apps/baselayout: 1.12.14-r1 sys-apps/sandbox: 2.4 sys-devel/autoconf: 2.65-r1 sys-devel/automake: 1.11.1 sys-devel/binutils: 2.20.1-r1 sys-devel/gcc: 4.4.4-r2 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.10 sys-devel/make: 3.81-r2 virtual/os-headers: 2.6.30-r1 (sys-kernel/linux-headers) ACCEPT_KEYWORDS="amd64" ACCEPT_LICENSE="* -@EULA dlj-1.1" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=k8 -O3 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/sandbox.d /etc/terminfo" CXXFLAGS="-march=k8 -O3 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="assume-digests binpkg-logs buildpkg distlocks fixlafiles fixpackages news parallel-fetch protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch" GENTOO_MIRRORS="http://distfiles.gentoo.org" LDFLAGS="-Wl,-O1 -Wl,--as-needed" MAKEOPTS="-j7" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/var/lib/layman/godin /usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="acl amd64 berkdb bzip2 cli cracklib crypt cups cxx dri fortran gdbm git gpm iconv ipv6 mercurial mmx modules mudflap multilib ncurses nls nptl nptlonly openmp pam pcre perl pppd python readline session sqlite3 sse sse2 ssl subversion sysfs tcpd unicode xorg zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ubx" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" PHP_TARGETS="php5-3" RUBY_TARGETS="ruby18" USERLAND="GNU" VIDEO_CARDS="fbdev glint intel mach64 mga neomagic nouveau nv r128 radeon savage sis tdfx trident vesa via vmware dummy v4l" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LANG, LC_ALL, LINGUAS, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
(In reply to comment #15) You haven't provided build log.
Created attachment 265895 [details] build.log from astng =============================================== compname ~ # python -c 'from distutils.command.install import install; \ > from distutils.dist import Distribution; x = install(Distribution()); \ > x.finalize_options(); print "purelib:", x.install_purelib; \ > print "platlib:", x.install_platlib; print "install_lib:", \ > x.install_lib' purelib: /usr/lib64/python2.6/site-packages platlib: /usr/lib64/python2.6/site-packages install_lib: /usr/lib64/python2.6/site-packages/ compname ~ # python2.4 -c 'from distutils.command.install import install; \ from distutils.dist import Distribution; x = install(Distribution()); \ x.finalize_options(); print "purelib:", x.install_purelib; \ print "platlib:", x.install_platlib; print "install_lib:", \ x.install_lib' purelib: /usr/lib/python2.4/site-packages platlib: /usr/lib64/python2.4/site-packages install_lib: /usr/lib/python2.4/site-packages/ compname ~ # cat /usr/portage/metadata/timestamp Fri Mar 11 22:06:39 UTC 2011 =============================================== build.log is attached. What I notice is that the 2.4-configured modules install to /usr/lib and the 2.6-configured modules install to /usr/lib64
