Well, this is what happens on my stable machine :( revdep-rebuild doesn't re-emerge apache, openldap and postfix after the removal of sys-libs/db-4.2.52_p4-r2 and installation of sys-libs/db-4.3 but depclean removes the urgently needed (as it seems) version 4.2.52_p4-r2 anyway. There must be something wrong with dependencies, I guess. I wasn't aware of the importancy of sys-libs/db, some words of warning on removal would have been nice ;) Reproducible: Always Steps to Reproduce: 1. emerge --depclean after upgrade to sys-libs/db-4.3 2. 3. Actual Results: various apps break because they seem to depend on sys-libs/db-4.2.52_p4-r2 which as been removed by depclean Expected Results: I don't know what would be the best solution... but at least there should be some warnings when removing the old sys-libs/db-version, so that users are aware that vital parts of their system won't work anymore afterwards...
(In reply to comment #0) > I don't know what would be the best solution... but at least there should be > some warnings when removing the old sys-libs/db-version, so that users are > aware that vital parts of their system won't work anymore afterwards... Like, this isn't enough of a warning? Run revdep-rebuild, thanks. *** WARNING *** Depclean may break link level dependencies. Thus, it is *** WARNING *** recommended to use a tool such as `revdep-rebuild` (from *** WARNING *** app-portage/gentoolkit) in order to detect such breakage.
> revdep-rebuild doesn't > re-emerge apache, openldap and postfix after the removal of > sys-libs/db-4.2.52_p4-r2 Read everything, please. Thanks.
The post gentoolkit version, exact revdep-rebuild command you used, attach the files it produced and reopen then. This is not a portage bug.
I was also hit by this but has since solved it manually by reemerging failing packages (apache and php). This is what I did: 1. I updated to sys-libs/db-4.3.29-r2. 2. 'emerge --with-bdeps --ask --verbose depclean' showed that the old db was not needed anymore. 3. I unmerged sys-libs/db-4.2.52_p4-r2. 4. revdep-rebuild resulted in this command: emerge --oneshot =dev-libs/apr-util-0.9.12 =dev-util/subversion-1.3.2-r3 5. Another revdep-rebuild showed no breakage. 6. '/etc/init.d/apache2 stop' resulted in an error (something about not finding the .so form the old sys-libs/db, sorry for not having the exact error message) 7. reemerged apache-2.0.58-r2 8. '/etc/init.d/apache2 stop' resulted in similar error, indicating that it now was php that couldn't find the db.so. 9. reemerged php-5.2.1-r3 10. Now everything works for me. I'm running a stable x86 system, portage-2.1.2.2, gentoolkit-0.2.3-r1. If you want complete emerge --info I'll be happy to attach it, didn't want to clutter this comment too much.
I also ran into difficulties with the upgrade of sys-libs/db from a 4.2ish Version to sys-libs/db-4.3.29-r2. Like in Comment #4 I unmerged the old sys-libs/db afterwards, ran a emerge -Dupv world to check wether some package depended on the old version (sys-libs/db did not show up again) and ran a revdep-rebuild. revdep-rebuild reported nothing, so I thought everything was fine -- until my machine quickly ran out of memory while using sa-learn (spamassassin). Calling sa-learn from a shell revealed that perl is also among the programms that did not like the upgrade of db, errors of sa-learn (before I killed it, I did not want to hard reset my machine again) showed the following lines: Use of uninitialized value in numeric ge (>=) at /usr/lib/perl5/5.8.8/i686-linux/DB_File.pm line 271. Use of uninitialized value in numeric gt (>) at /usr/lib/perl5/5.8.8/i686-linux/DB_File.pm line 275. Deep recursion on subroutine "DB_File::AUTOLOAD" at /usr/lib/perl5/5.8.8/i686-linux/DB_File.pm line 234. My system is mostly stable x86 (db, perl are at stable Versions, spamassassin is currently ~x86). gentoolkit version: 0.2.3-r1 portage version: 2.1.2.2 revdep-rebuild command: revdep-rebuild -i -p I do not have the original output of revdep-rebuild nor the old output files of revdep-rebuild (as they were deleted after the run of revdep-rebuild), but a current run (perl is not rebuild yet, but will be shortly) yields the following (revdep-rebuild files are automagically gone again): lud ~ # revdep-rebuild -i -p Configuring search environment for revdep-rebuild Checking reverse dependencies... Packages containing binaries and libraries broken by a package update will be emerged. Collecting system binaries and libraries... done. (/root/.revdep-rebuild.1_files) Collecting complete LD_LIBRARY_PATH... done. (/root/.revdep-rebuild.2_ldpath) Checking dynamic linking consistency... done. (/root/.revdep-rebuild.3_rebuild) Assigning files to ebuilds... Nothing to rebuild Evaluating package order... done. (/root/.revdep-rebuild.5_order) Dynamic linking on your system is consistent... All done. emerge info: Portage 2.1.2.2 (default-linux/x86/2006.1, gcc-4.1.1, glibc-2.5-r0, 2.6.19-suspend2-r3 i686) ================================================================= System uname: 2.6.19-suspend2-r3 i686 Genuine Intel(R) CPU T2050 @ 1.60GHz Gentoo Base System release 1.12.9 Timestamp of tree: Tue, 03 Apr 2007 09:00:09 +0000 dev-java/java-config: 1.3.7, 2.0.31 dev-lang/python: 2.4.3-r4 dev-python/pycrypto: 2.0.1-r5 sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.61 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.16.1-r3 sys-devel/gcc-config: 1.3.14 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.17-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=prescott -O2 -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/java-config/vms/ /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c" CXXFLAGS="-march=prescott -O2 -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="distlocks metadata-transfer parallel-fetch sandbox sfperms strict userfetch" GENTOO_MIRRORS="ftp://pandemonium.tiscali.de/pub/gentoo/ ftp://ftp.gentoo.mesh-solutions.com/gentoo/ " LINGUAS="de en en_US" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --filter=H_**/files/digest-*" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X acpi aiglx alsa arts avi bash-completion berkdb bitmap-fonts bzip2 cairo cli cracklib crypt curl dbus dri dvd dvdr encode exif ffmpeg flac fortran gdbm gif gpm hal iconv isdnlog jpeg kde kdeenablefinal kdehiddenvisibility latex libg++ mad midi mmx mmxext mp3 mpeg ncurses nls nptl nptlonly ntpl ogg opengl pam pcre pdf perl png pppd python qt qt3 qt4 readline reflection sdl session speex spell spl sse sse2 sse3 ssl svg tcpd tetex theora tiff truetype truetype-fonts type1-fonts unicode usb vorbis x264 x86 xml xorg xv xvmc zlib" ALSA_CARDS="hda-intel" 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" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="de en en_US" USERLAND="GNU" VIDEO_CARDS="i810" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Folks, if you want to get someone investigate the revdep-rebuild problem, you'll need to attach the complete logs here. AFAICT, re-emerging dev-libs/apr-util (both slots if you have them) should get it working again.
(In reply to comment #6) > Folks, if you want to get someone investigate the revdep-rebuild problem, > you'll need to attach the complete logs here. I take it that there is some switch then that stops revdep-rebuild from removing the log files? The man page does not mention such a switch, and at least .revdep-rebuild.3_rebuild and .revdep-rebuild.5_order were deleted within less than a second of completion, as there was nothing found to be rebuild. If there is indeed such a switch (or some other easy way to obtain the full logs), or if attaching .revdep-rebuild.0_env, .revdep-rebuild.1_files and .revdep-rebuild.2_ldpath really helps, I will gladly try recreating the broken situation - otherwise it is too much hassle for nothing. By the way, dev-libs/util-apr is not installed on my system, so I guess that part of the comment was not directed towards me. And as I had no problem fixing the situation once I found out what was causing it, I do not really need this fixed, but it would be nice if such brokenness could be somehow detected in the future.
(In reply to comment #7) > I take it that there is some switch then that stops revdep-rebuild from > removing the log files? `revdep-rebuild [whatever other options here] -p` will just tell you what it would do and keep all the logs in /root.
(In reply to comment #8) > (In reply to comment #7) > > I take it that there is some switch then that stops revdep-rebuild from > > removing the log files? > > `revdep-rebuild [whatever other options here] -p` will just tell you what it > would do and keep all the logs in /root. Is that supposed to work as well when revdep-rebuild does not call emerge as there are no packages it wants to rebuild? I just tried and it did not help, but then again my system is in a sane state right now. Ok, I will try and downgrade db, remove the current one, rebuild perl against the old version, upgrade db again and remove the old Version of db. I do fear that I will not be able to keep complete logs afterwards though.
(In reply to comment #9) > Ok, I will try and downgrade db, remove the current one, rebuild perl > against the old version, upgrade db again and remove the old Version of db. Sorry, I cannot (easily) reproduce the problem, this time revdep-rebuild correctly reports that perl has to be rebuild.
