Bug 356609 – www-client/chromium-bin-9.0.597.84 stopped working after libevent upgrade

• Product: Gentoo Linux
• Status: RESOLVED WONTFIX

[Description Leonid Podolny 2011-02-26 18:59:51 UTC]

After libevent upgraded to 2.0.10:

user@box ~ % chromium-bin 
/opt/chromium.org/chrome: error while loading shared libraries: libevent-1.4.so.2: cannot open shared object file: No such file or directory

[Comment 1 Mike Gilbert 2011-02-26 19:35:27 UTC]

The source-based chromium package is less fragile. If you have the hardware for it, I suggest you switch to that.

[Comment 2 meyerm 2011-03-01 13:13:31 UTC]

Just out of curiosity. Would a slotting of the library help in this case? Can't libevent-1.* be installed in parallel to libevent-2.*? If yes, is there a reason why it isn't done? Thanks!

[Comment 3 walt 2011-03-01 15:07:29 UTC]

(In reply to comment #1)
> The source-based chromium package is less fragile. If you have the hardware for
> it, I suggest you switch to that.

Same problem with the source-based package -- and revdep-rebuild doesn't find the breakage, which is the real problem.

The "chrome" executable is stored in /usr/lib64/chromium-browser where revdep-rebuild doesn't look for executables, just libraries.  Maybe this should be a bug against revdep-rebuild?

[Comment 4 Mike Gilbert 2011-03-02 00:42:46 UTC]

(In reply to comment #3)
> Same problem with the source-based package -- and revdep-rebuild doesn't find
> the breakage, which is the real problem.

I guess I really meant that the source-based package is fixable by rebuilding it. With the binary, you have to wait until a dev rebuilds it.

Not sure on revdep-rebuild. I run portage-2.2 with preserve-libs, and I think that would have caught this.

[Comment 5 Paweł Hajdan, Jr. (RETIRED) 2011-03-05 17:21:13 UTC]

chromium-bin has been masked for removal.