After upgrading to dev-libs/expat-2.0.1 revdep-rebuild showed dev-libs/apr-util to be broken. I reemerged it, then completely upgraded my system, them remerged it again, but it is still shown broken. Reason was about slots. I have two slots of apr-util installed, their versions are 0.9.12 and 1.2.8. The revdep-rebuild output states "broken /usr/lib/libaprutil-0.so.0.9.12 (requires libexpat.so.0)" But the package that is to be emerged is "All prepared. Starting rebuild... emerge --oneshot -p =dev-libs/apr-util-1.2.8" I guess revdep-rebuild misses the slot. I have not manually remerged the correct version in case we need further tests. Here is equery output. $ equery belongs /usr/lib/libaprutil-0.so.0.9.12 dev-libs/apr-util-0.9.12 (/usr/lib/libaprutil-0.so.0.9.12) $ equery list apr-util [I--] [ ] dev-libs/apr-util-0.9.12 (0) [I--] [ ] dev-libs/apr-util-1.2.8 (1) Here is ldd output, and apr-util-0.9.12 is indeed broken, whereas apr-util-1.2.8 is not. $ ldd /usr/lib/libaprutil-1.so.0.2.8 linux-gate.so.1 => (0xffffe000) libldap-2.3.so.0 => /usr/lib/libldap-2.3.so.0 (0xb7f5f000) liblber-2.3.so.0 => /usr/lib/liblber-2.3.so.0 (0xb7f53000) libgdbm.so.3 => /usr/lib/libgdbm.so.3 (0xb7f4d000) libdb-4.3.so => /usr/lib/libdb-4.3.so (0xb7e70000) libsqlite3.so.0 => /usr/lib/libsqlite3.so.0 (0xb7e14000) ===>libexpat.so.1 => /usr/lib/libexpat.so.1 (0xb7df5000) libapr-1.so.0 => /usr/lib/libapr-1.so.0 (0xb7dd3000) libuuid.so.1 => /lib/libuuid.so.1 (0xb7dd0000) librt.so.1 => /lib/librt.so.1 (0xb7dc7000) libcrypt.so.1 => /lib/libcrypt.so.1 (0xb7d99000) libpthread.so.0 => /lib/libpthread.so.0 (0xb7d82000) libdl.so.2 => /lib/libdl.so.2 (0xb7d7e000) libc.so.6 => /lib/libc.so.6 (0xb7c5d000) libresolv.so.2 => /lib/libresolv.so.2 (0xb7c4b000) libssl.so.0.9.8 => /usr/lib/libssl.so.0.9.8 (0xb7c0e000) libcrypto.so.0.9.8 => /usr/lib/libcrypto.so.0.9.8 (0xb7ae2000) /lib/ld-linux.so.2 (0x80000000) $ ldd /usr/lib/libaprutil-0.so.0.9.12 linux-gate.so.1 => (0xffffe000) libldap-2.3.so.0 => /usr/lib/libldap-2.3.so.0 (0xb7eac000) liblber-2.3.so.0 => /usr/lib/liblber-2.3.so.0 (0xb7ea0000) libgdbm.so.3 => /usr/lib/libgdbm.so.3 (0xb7e9a000) libdb-4.3.so => /usr/lib/libdb-4.3.so (0xb7dbd000) ===>libexpat.so.0 => not found libapr-0.so.0 => /usr/lib/libapr-0.so.0 (0xb7d9d000) librt.so.1 => /lib/librt.so.1 (0xb7d94000) libm.so.6 => /lib/libm.so.6 (0xb7d70000) libcrypt.so.1 => /lib/libcrypt.so.1 (0xb7d42000) libnsl.so.1 => /lib/libnsl.so.1 (0xb7d2d000) libpthread.so.0 => /lib/libpthread.so.0 (0xb7d16000) libdl.so.2 => /lib/libdl.so.2 (0xb7d12000) libc.so.6 => /lib/libc.so.6 (0xb7bf1000) libresolv.so.2 => /lib/libresolv.so.2 (0xb7bdf000) libssl.so.0.9.8 => /usr/lib/libssl.so.0.9.8 (0xb7ba2000) libcrypto.so.0.9.8 => /usr/lib/libcrypto.so.0.9.8 (0xb7a76000) /lib/ld-linux.so.2 (0x80000000) Reproducible: Always Steps to Reproduce: 1. upgrade expat to 2.0.1 which breaks ABI 2. run revdep-rebuild 3. run revdep-rebuild again Actual Results: dev-libs/apr-util-1.2.8 is tried to be built again and again Expected Results: dev-libs/apr-util-0.9.12 should be built instead
Did you run revdep-rebuild -X or just revdep-rebuild?
(In reply to comment #1) > Did you run revdep-rebuild -X or just revdep-rebuild? > I was in process of upgrading to KDE 3.5.7 and I have been running with -X switch. Removing the switch tried to remerge correct version. I think slots should be handled differently in revdep-rebuild, as they are not a regular version change, but two different set of files exist. The man page for -X says "emerge the best packages available" but I believe it should look for the highest version in the current slot.
Well, if you want to re-emerge some slotted app, you have emerge by version. And -X states clearly, that it emerges by name. And that always emerges the highest slot available.
-X won't work for slotted stuff.
This is a non-issue in the upcoming new release of revdep-rebuild
*** Bug 190972 has been marked as a duplicate of this bug. ***
(In reply to comment #4) > -X won't work for slotted stuff. It should according to the code. Otherwise I'd *really* love to know why it's moving package.mask around... (In reply to comment #5) > This is a non-issue in the upcoming new release of revdep-rebuild Yep. So this bug can be marked resolved fixed once upcoming releases have been stabilized (or even just 0.2.4_pre5).
Reopening for reassignment
Actually, it works for every case except when SLOT=0. I'm still trying to get clarification, but SLOT=0 used to mean that the package was not slottable, which revdep-rebuild uses to try to avoid mucking with /etc/portage/package.mask
(In reply to comment #9) > Actually, it works for every case except when SLOT=0. I'm still trying to > get clarification, but SLOT=0 used to mean that the package was not > slottable, which revdep-rebuild uses to try to avoid mucking with > /etc/portage/package.mask Below is an exhaustive list of the 44 packages currently in gentoo-x86 that have more than one slot where one of those is SLOT=0. Combined they occupy 101 slots (2.3 slots pr. package on average). For comparison there are currently 259 packages in gentoo-x86 that have more than one slot (including the 44 below). ;) app-arch/unace app-crypt/gnupg app-text/docbook-xml-simple-dtd dev-cpp/libxmlpp dev-db/oracle-instantclient-basic dev-db/oracle-instantclient-jdbc dev-db/oracle-instantclient-sqlplus dev-db/sqlite dev-java/commons-betwixt dev-java/commons-httpclient dev-java/commons-lang dev-java/ehcache dev-java/gnu-classpath dev-java/java-config dev-java/jcommon dev-java/jfreechart dev-java/prefuse dev-java/saxon dev-lang/gnat dev-libs/apr dev-libs/apr-util dev-libs/libcroco dev-libs/lzo dev-ml/pcre-ocaml dev-python/gst-python dev-python/psycopg dev-python/pysqlite dev-python/sancho dev-util/cvsweb dev-util/netbeans games-rpg/nwn-cep gnome-extra/libgnomedb media-libs/libmpd media-libs/libvisual media-plugins/libvisual-plugins net-wireless/ipw2200-firmware net-zope/plone net-zope/portaltransforms net-zope/zodb sci-geosciences/grass sys-boot/grub sys-libs/slang www-apps/viewcvs x11-libs/qwt
(In reply to comment #9) > Actually, it works for every case except when SLOT=0. I'm still trying to get > clarification, but SLOT=0 used to mean that the package was not slottable, > which revdep-rebuild uses to try to avoid mucking with > /etc/portage/package.mask If a package isn't slotted it's supposed to use SLOT=0, but SLOT=0 doesn't strictly mean that no other SLOTs may exist (it should be avoided as it can cause confusion, but it's not illegal. SLOT="" however is, but don't ask me why). Not sure why it matters anyway, should be technically no difference if the ebuilds of a package all use SLOT=0 or SLOT=1.
Can someone please test this against revdep-rebuild in app-portage/gentoolkit-0.2.4_rc2?
