Never-ending revdep-rebuild

sl70 · Guru Joined: 18 Jun 2002 Posts: 449 Location: Saitama, JP

I've been having the problem for a while and can't figure out how to fix it. No matter how many times I do revdep-rebuild, it keeps telling me that I need to rebuild the same 7 packages.

dol-sen · Posted: Thu Jun 21, 2012 2:23 pm Post subject:

hmm, if it can't find something that is there... check your PATHS.
_________________
Brian
Porthole, the Portage GUI frontend irc@freenode: #gentoo-guis, #porthole, Blog
layman, gentoolkit, CoreBuilder, esearch...

sl70 · Guru Joined: 18 Jun 2002 Posts: 449 Location: Saitama, JP

Right. That sounds like a very good idea. So, I edited /etc/ld.so.conf but that didn't help -- it got overwritten when I ran ldconfig. Then I noticed that it says I'm supposed to make changes to the appropriate file in /etc/env.d. However, there is not file for firefox, thunderbird, vigra or any of the other packages I'm having trouble with. Can you point me to the documentation for me to read about this?

Thanks.

gienah · Developer Joined: 24 Nov 2010 Posts: 212 Location: AU

Maybe this might give some hints:

vitaly_repin · n00b Joined: 05 Jun 2011 Posts: 12

Hello,

I have the same problem.

I have installed:

wrc1944 · Posted: Sun Mar 30, 2014 3:23 pm Post subject:

I'm running into this exact problem on an ~x86 box, firefox-28.0, but only says I need to rebuild Firefox.

A revdep-rebuild "emerge --complete-graph=y --oneshot --quiet-build=n www-client/firefox:0" rebuilds firefox OK, but a subsequent revdep-rebuild still says firefox is still broken, as before.

Another firefox rebuild results in the same thing. Firefox appears to be running perfectly normal, so it also seems totally bogus, as sl70 comments.

Emerge --depclean reports nothing to remove, and "emerge --update --deep --with-bdeps=y --newuse @world" offers nothing to do.

dol-sen · Posted: Sun Mar 30, 2014 4:22 pm Post subject:

It seems that mozilla does some path mangling when the applications start. It then finds the bundled libs that are reported broken by revdep-rebuild.
_________________
Brian
Porthole, the Portage GUI frontend irc@freenode: #gentoo-guis, #porthole, Blog
layman, gentoolkit, CoreBuilder, esearch...

furanku · Posted: Thu Apr 17, 2014 1:25 pm Post subject:

Does someone work on this problem?

colo-des · Tux's lil' helper Joined: 20 May 2011 Posts: 97

I've solved after hard experimentation, what happens is that the ebuild of firefox-28 apparently does not put the /etc/ld.so.conf the path to their libraries.

steveL · Posted: Mon Apr 21, 2014 3:48 pm Post subject:

@colo-des: That's great work, but I'm afraid you can't in general, just go adding package-private libexec dirs to ld.so.conf. It's fine as a workaround in this specific case, given that Gentoo does not bundle any system libs. But it has to be verified on every upgrade: the list could well change at any time, as any upstream rightly considers libexecdir/pkg a private directory. The point of libexecdir is to ensure the package uses the libs it installed over any other, without affecting other package or app library loading; ie those libs are not meant to be picked up by ldd by default.

So it's not a general solution, as some packages require a specific, typically patched in-house, version of a lib the main system already has (chromium comes to mind.) I'm not saying you posited it as one, simply that a more general solution is of interest.

Either we give revdep a list of exceptions, along with a directory or directories to check for the specific package (gack), or we record linkage at install-time (done under preserved-rebuild) and tie revdep into that: ie revdep should fallback to checking that data when it thinks a library is missing.

It should also check whether the object it is scanning is in fact a preserved-rebuild, since that causes never-ending cycles too, or still did a few months ago, with gmp/mpfr and gcc.

In essence: portage is finally recording linkage; revdep should make use of that info, if it's available.

Thankfully dol-sen has spent the last few years making the portage api much more accessible, as well as rewriting gentoolkit, before his current stint as portage lead. So I for one have hope that revdep will be updated; it's only fairly recently been rewritten in python, after all.

Most of all I'm glad we have someone leading it, who knows how important it is to keep a stable output for other scripts, since much of his prior work was based on wrapping portage. Even if there is now a python api, that experience is very useful, as it mirrors normal usage, and it doesn't fade easily.

Nerevar · l33t Joined: 31 May 2008 Posts: 720

Working off @colo-des great research, I created the file /etc/env.d/99firefox with the following:

SamuliSuominen · Posted: Tue May 06, 2014 5:06 am Post subject:

aruberutsu · n00b Joined: 06 May 2014 Posts: 1

A quick workaround is to set

Nerevar · l33t Joined: 31 May 2008 Posts: 720

Alright Samuli. I only have firefox installed, but I've reverted that change just to be safe. I'll try the mask mentioned and see if that allows revdep-rebuild to be happy. Ignoring the issue is not an option for my OCD.

Thank you!

dol-sen · Posted: Wed May 07, 2014 11:39 pm Post subject:

Yes, the SEARCH_DIRS_MASK="/usr/lib64/firefox" is the correct way to fix this.
_________________
Brian
Porthole, the Portage GUI frontend irc@freenode: #gentoo-guis, #porthole, Blog
layman, gentoolkit, CoreBuilder, esearch...

Anarchy · Developer Joined: 29 Jun 2005 Posts: 140

Dimetra · n00b Joined: 11 Mar 2014 Posts: 4

There appears to be a similar issue with "mail-client/thunderbird-24.4.0".

SEARCH_DIRS_MASK="/usr/lib64/firefox /usr/lib64/thunderbird" appears to resolve it. I assume this is equally safe(?).

SamuliSuominen · Posted: Thu May 22, 2014 6:37 am Post subject:

steveL · Posted: Fri May 23, 2014 7:46 am Post subject: