Bug 611428 – net-misc/memcached-1.4.33: libevent dependency does not use := slot operator (already fixed in 1.4.33-r1)

• Product: Gentoo Linux
• Status: RESOLVED FIXED

[Description Erik Dannenberg 2017-03-02 18:43:57 UTC]

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?

[Comment 1 Ural 2017-03-03 06:41:08 UTC]

I have same issue. I think not only memcached affected, but it is great example

[Comment 2 Michael Palimaka (kensington) 2017-03-03 23:37:48 UTC]

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?

[Comment 3 Berne Campbell 2017-03-06 04:52:43 UTC]

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

[Comment 4 Michael Palimaka (kensington) 2017-03-06 10:09:59 UTC]

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.

[Comment 5 Zac Medico 2017-03-06 22:17:30 UTC]

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.