A recent system update pulled in dev-libs/libevent-2.1.8, but a reinstall of net-misc/memcached failed to recognize this and used a binary package linked against libevent-2.0.22 instead of recompiling. To reproduce the issue: > # echo $FEATURES > parallel-fetch nodoc noinfo noman binpkg-multi-instance > # echo $EMERGE_DEFAULT_OPTS > -b -k Mask libevent 2.1.8 and install/downgrade if required: > # echo '>=dev-libs/libevent-2.1.8' > /etc/portage/package.mask/foo > # emerge -pv dev-libs/libevent Should look like this: > # equery l dev-libs/libevent > * Searching for libevent in dev-libs ... > [IP-] [ ] dev-libs/libevent-2.0.22:0 Install memcached and create a binary package: > # emerge -v net-misc/memcached Remove libevent mask: > # rm /etc/portage/package.mask/foo Install memcached again, to illustrate the problem better at a custom ROOT: > # ROOT=/foo emerge -pv net-misc/memcached > These are the packages that would be merged, in order: > Calculating dependencies... done! > [ebuild N ] dev-libs/libevent-2.1.8:0/2.1-6::gentoo to /foo/ USE="ssl threads -debug (-libressl) -static-libs {-test}" 0 KiB > [binary N ] net-misc/memcached-1.4.33-1::gentoo to /foo/ USE="-debug -sasl (-selinux) -slabs-reassign {-test}" 0 KiB So a new libevent 2.1.8 version is installed, but the binary package linked against libevent 2.0.22 is used, resulting in runtime errors as the old libevent version does not exit. This was also reproducable without using a custom ROOT and simply updating libevent. This is the first time I ran into such an issue, maybe this is a quirk in the memcached ebuild?
I have same issue. I think not only memcached affected, but it is great example
I'm a little confused about what's happening. Where does the binary libevent-2.0.22 come from once the upgrade to libevent-2.1.8 is done - portage's preserved-libs?
Hi Michael, I have also reproduced this issue. (In reply to Michael Palimaka (kensington) from comment #2) > I'm a little confused about what's happening. Where does the binary > libevent-2.0.22 come from once the upgrade to libevent-2.1.8 is done - > portage's preserved-libs? This happened because of a series of events like the following: - 1. first memcache (with dependency pulling in libevent-2.0.22) installed and binary packages built 2. memcache + libevent-2.0.22 uninstalled 3. libevent-2.1.8 installed due to depenencies of something other than memcache. 4. install memcache from binary package portage believes libevent-2.1.8 satisifies the memcache dependencies memcache is broken. memcache will be broken because binary package is linked to old sonames from libevent-2.0.22 that no longer exist in libevent-2.1.8. Binary packages are often used and shared between a farm of Gentoo machines to speed things up. So are another common scenario this occurs in: - 1. MachineA installs memcache + dependency libevent-2.0.22 building binary packages 2. MachineB updates portage etc. libevent-2.1.8 is installed 3. MachineB installs memcache binary package it got from MachineA Portage thinks libevent-2.1.8 is fine because dependencies match memcache is broken because it's linking to old SONAMEs If `--ignore-soname-deps=n` is enabled emerge will catch the issue and install the older libevent to meet teh soname dependencies, but this will only work everything is binary packages. In the two scenarios above running `revdep-rebuild` will detect the breakage. Thanks, Berne
Thanks for the further detail, Berne. This is strange behaviour given that libevent-2.0.22 has an implicit subslot of '0' and libevent-2.1.8 an explicit 2.1-6 - in my experience portage normally catches this when dealing with binary packages.
The issue is that the memcached-1.4.33 ebuild does not use a := slot operator dependency for libevent. It's fixed in the memcached-1.4.33-r1 ebuild, which doesn't have a stable keyword yet.
