On my server box, Portage 2.0.46-r4 insists to delete the wrong package versions: # emerge -pc >>> These are the packages that I would unmerge: dev-perl/TermReadKey selected: 2.19-r1 protected: 2.19 omitted: none sys-apps/xinetd selected: 2.3.9 protected: 2.3.7 omitted: none app-admin/ufed selected: 0.2 protected: 0.1 omitted: none net-misc/ntp selected: 4.1.1b-r3 protected: 4.1.1b-r1 omitted: none >>> Packages in red are slated for removal. >>> Packages in green will not be removed. I know this shouldn't be happening, but I really don't have a clue what's going on here. I reinstalled portage-2.0.46-r4 to make sure, but to no avail. Right now, I have to manually execute "emerge -C '<category/package-newestversion'" to make sure Portage doesn't delete important files (I've had this happened with shadow, resulting in a missing /bin/su! I just noticed that by pure coincidence.) For the time being, I'm not uninstalling packages on the box right now, so if you need any more info or files from the box, _please_ ask me. Here the "emerge info" from that box: Portage 2.0.46-r4 (default-1.0, gcc-2.95.3, glibc-2.2.5-r7) ================================================================= System uname: 2.4.18 i686 Pentium III (Katmai) USE="x86 apm crypt encode gif imlib jpeg libg++ mmx motif mpeg ncurses svga truetype xml2 xv berkdb gdbm java libwww pam png python readline slang ssl tcpd tiff -3dnow -arts -avi -cups -gpm -gtk -kde -mikmod mysql -nls -oggvorbis -opengl -oss -pdflib perl -qt -qtmt -quicktime sasl -sdl -spell -X -xmms" ARCH="x86" COMPILER="" CHOST="i686-pc-linux-gnu" CFLAGS="-march=i686 -O3 -funroll-loops -pipe" CXXFLAGS="-march=i686 -O3 -funroll-loops -pipe" ACCEPT_KEYWORDS="x86" CONFIG_PROTECT="/etc /var/qmail/control /usr/share/config /usr/kde/2/share/config /usr/kde/3/share/config /opt/jakarta/tomcat/conf" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" MAKEOPTS="" JDK_HOME="/opt/sun-jdk-1.4.1.01" JAVA_HOME="/opt/sun-jdk-1.4.1.01" AUTOCLEAN="no" SYNC="rsync://localhost/gentoo-portage" GENTOO_MIRRORS="ftp://ftp.sunsite.dk/mirrors/gentoo"
One thing I forgot to say: I'm using the same Portage version on my home box, and there's no problem with it. Again, I don't have a clue what's going on here :-( Here's the info from my home box: Portage 2.0.46-r4 (default-1.0, gcc-2.95.3, glibc-2.2.5-r7) ================================================================= System uname: 2.4.20-bz1 i686 AMD Athlon(tm) Processor USE="x86 oss 3dnow apm avi crypt cups jpeg libg++ libwww mikmod mmx mpeg ncurses quicktime truetype xml2 xmms xv berkdb bonobo cdr esd gdbm gif gnome-libs gpm gtk guile imlib java ldap mozilla nls oggvorbis opengl pam perl png readline sdl slang ssl tcltk tiff X alsa -arts dvd -encode gnome jikes -kde -motif mysql -pdflib -python -qt -qtmt samba sasl -spell -svga -tcpd" ARCH="x86" COMPILER="" CHOST="i686-pc-linux-gnu" CFLAGS="-march=i686 -O3 -funroll-loops -pipe" CXXFLAGS="-march=i686 -O3 -funroll-loops -pipe" ACCEPT_KEYWORDS="x86 ~x86" CONFIG_PROTECT="/etc /var/qmail/control /usr/share/config /usr/kde/2/share/config /usr/kde/3/share/config" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" MAKEOPTS="" JDK_HOME="/opt/sun-j2sdk-1.4.0" JAVA_HOME="/opt/sun-j2sdk-1.4.0" AUTOCLEAN="no" SYNC="rsync://194.97.4.250/gentoo-portage" GENTOO_MIRRORS="ftp://ftp.sunsite.dk/mirrors/gentoo"
In http://article.gmane.org/gmane.linux.gentoo.devel/6083, a user describes having about the same Problem - Portage insisting on deleting newer versions, while keeping old ones. Again, this results in missing files. (The user seems to be using AUTOCLEAN=yes and having installed some ~x86 packages, while having ACCEPT_KEYWORDS="x86" at the same time. Those facts should really be irrelevant IMHO.)
theses packages are all stable even on my 1.2 gentoo
Use a newer portage if you are sure it's only unmerging the most recently installed versions... probably a counter problem. If it's a counter problem the update should fix your problems. You should 'emerge -e world' after getting on portage-2.0.46-r5 You may have a great deal of counter corruption if the update doesn't fix it. You could have hit a bad mirror and got a zero'd package.mask like I did. And portage is now unmerging the old versions.
As I expected from having remerged portage-2.0.46-r4 before, the update to portage-2.0.46-r5 didn't work. Since you said something about counters, I had a quick look: In /var/db/pkg, the COUNTER for portage-2.0.46-r4 is 19, while the COUNTER for 2.0.46-r5 is 14. What exactly do these numbers mean? The thing is, I want to understand how that counter mechanism works, so that I can perhaps fix my db myself. I find remerging all 193 packages really not acceptable. Any help is deeply appreciated!
Now that's interesting: After I updated to portage-2.0.46-r5, "emerge -pc" showed me the same behaviour I described. Now, I've just updated Mail-SpamAssassin and Time-HiRes, and for those two it works! I will try and clean those two, if it doesn't work, I will add another comment here. sys-apps/portage selected: 2.0.46-r5 protected: 2.0.46-r4 omitted: none dev-perl/Time-HiRes selected: 01.20-r2 protected: 1.38 omitted: none dev-perl/Mail-SpamAssassin selected: 2.43-r2 protected: 2.43-r3 omitted: none
Alright, this has been identified as COUNTERs in /var/db/pkg having the wrong order. I've written a script that fixes this: http://cvs.gentoo.org/~blizzy/fix-db.pl Make sure to backup /var/db/pkg/* first! (/var/cache/edb/counter can be deleted safely, no need to backup.) Carpaski, perhaps I just leave this bug open for you to add stuff to Portage?
I tried using the script because I encountered the same strange behavior. It resulted in: rabbing db contents... Grabbing mtimes... fix-db: fatal: insufficient data for app-text/docbook-sgml-1.0
Benjamin: Yes, these errors are quite common if there is not enough data to be found in a package's CONTENTS file. Workaround: Remove the package's complete directory from /var/db/pkg, then re-run the script. If all goes well, you just need to remerge the package after the script is done (so to not break any dependencies).
Pulled the script into portage. It's there, as a just-in-case.
