Only apache2 is installed, emerging mod_php-4.3.3-r3 installs correctly. etcat -v mod_php is reporting that mod_php is installed in slot 1, but the SLOT-file in /var/db/pkg/dev-php/mod_php-4.3.3-r3 contains 2. Reproducible: Always Steps to Reproduce: 1. etcat -v mod_php 2. cat /var/db/pkg/dev-php/mod_php-4.3.3-r3/SLOT 3. Actual Results: etcat reports SLOT 1 and cat shows SLOT 2 Expected Results: both etcat and cat should report SLOT 2 Portage 2.0.49-r15 (default-x86-1.4, gcc-3.2.3, glibc-2.2.5-r2,2.3.2-r1, 2.6.0-test5) ================================================================= System uname: 2.6.0-test5 i686 Intel(R) Pentium(R) 4 CPU 2.00GHz Gentoo Base System version 1.4.3.10p1 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-march=pentium3 -O3 -pipe" CHOST="i686-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /var/qmail/control /usr/kde/2/share/config /usr/kde/3/share/config /usr/X11R6/lib/X11/xkb /usr/kde/3.1/share/config /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/config" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" CXXFLAGS="-march=pentium3 -O3 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="sandbox ccache autoaddcvs fixpackages" GENTOO_MIRRORS="http://gentoo.linux.no http://gentoo.oregonstate.edu/ http://www.ibiblio.org/pub/Linux/distributions/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="foomaticdb mad zlib gtkhtml tetex bonobo guile perl esd ldap x86 -3dnow apm arts apache2 avi berkdb crypt cups encode gd gdbm gif -gnome -gpm gtk gtk2 imap imlib java jpeg -kde libg++ libwww maildir -mikmod mmx motif mpeg mysql ncurses nls oci8 odbc oggvorbis opengl oss pam pdflib png postgres python qt qtmt quicktime readline sasl sdl slang spell ssl svga tcltk tcpd truetype X xml2 xmms xv"
it is one of the problems with the mod_php ebuild setting SLOT="${APACHE_VER}". etcat gets the data from portage and the metadata was generated with APACHE_VER = 1. although for me it is a little difference because i'm not using the metadata cache generated from the rsync server. % etcat -v mod_php [ Results for search key : mod_php ] [ Applications found : 1 ] * dev-php/mod_php : [ ] dev-php/mod_php-4.3.2 (0) [ ~ ] dev-php/mod_php-4.3.2-r1 (1) [ ~ ] dev-php/mod_php-4.3.2-r2 (2) [ ] dev-php/mod_php-4.3.2-r3 (2) [ ] dev-php/mod_php-4.3.2-r4 (2) [ ~ ] dev-php/mod_php-4.3.2-r5 (2) [M ] dev-php/mod_php-4.3.3_rc3 (2) [ ~ ] dev-php/mod_php-4.3.3 (2) [ ] dev-php/mod_php-4.3.3-r1 (2) [ ] dev-php/mod_php-4.3.3-r2 (2) % for x in /var/cache/edb/dep/dev-php/mod_php-4.3.*; do echo "`basename $x`: `cat $x | head -n 3 | tail -n 1`"; done mod_php-4.3.2: 0 mod_php-4.3.2-r1: 1 mod_php-4.3.2-r2: 2 mod_php-4.3.2-r3: 2 mod_php-4.3.2-r4: 2 mod_php-4.3.2-r5: 2 mod_php-4.3.3: 2 mod_php-4.3.3-r1: 2 mod_php-4.3.3-r2: 2 mod_php-4.3.3_rc3: 2 don't know how to fix it really, or if it is a etcat problem or portage problem.
Another effect of this is that "emerge -p" shows some mod_php updates as if they were some new install (I mean, some "install in a new slot" in fact, which is also "N")... This is not very surprising tho, it is the exact same kind of aux_get call. Maybe there should have some kind of "nocache" restrict flag in ebuilds that use dynamic values for this kind of metadata, and aux_get would not try to read/write in cache for them. That way, it would each time recompute an up-to-date value. (Yes, it would slow down a few things, but there are very few such ebuilds.) Because up-to-date values are okay, it is really only a problem of cache. For instance: % etcat -v mod_php [...] [ ] dev-php/mod_php-4.3.3-r3 (1) (slot is wrong) % touch /usr/portage/dev-php/mod_php/mod_php-4.3.3-r3.ebuild % etcat -v mod_php [...] [ ] dev-php/mod_php-4.3.3-r3 (2) (slot is now right)
true, basically, dynamic slots will produce weird results, same as dynamic depends. it is something that is not fundamentally etcat's fault but the way we need to have dynamic slots. i can't really fix that behaviour unfortuantely.
You will be able to fix this bug for real if portage patch from bug #32367 is accepted by portage team. In that case, you will only have to add RESTRICT="nocache" to mod_php ebuilds (and also to mod_scgi and mod_pcgi2 for the same reason).
