See summary. It seems blackdown-jdk needs alsa or something: broken /opt/blackdown-jdk-1.4.2.01/jre/lib/i386/libjsoundalsa.so (requires libasound.so.2) Reproducible: Always Steps to Reproduce: 1. while :; do 2. rm /root/.revdep-rebuild.* 3. revdep-rebuild -p 4. revdep-rebuild 5. done Actual Results: # revdep-rebuild -p Checking reverse dependencies... Packages containing binaries and libraries broken by any package update, will be recompiled. Collecting system binaries and libraries... done. (/root/.revdep-rebuild.1_files) Collecting complete LD_LIBRARY_PATH... done. (/root/.revdep-rebuild.2_ldpath) Checking dynamic linking consistency... broken /opt/blackdown-jdk-1.4.2.01/jre/lib/i386/libjsoundalsa.so (requires libasound.so.2) done. (/root/.revdep-rebuild.3_rebuild) Assigning files to ebuilds... done. (/root/.revdep-rebuild.4_ebuilds) Evaluating package order... done. (/root/.revdep-rebuild.5_order) All prepared. Starting rebuild... emerge --oneshot --nodeps -p =dev-java/blackdown-jdk-1.4.2.01 These are the packages that I would merge, in order: Calculating dependencies ...done! [ebuild R ] dev-java/blackdown-jdk-1.4.2.01 Now you can remove -p (or --pretend) from arguments and re-run revdep-rebuild. Expected Results: :-) Gentoo Base System version 1.4.16 Portage 2.0.51-r15 (default-linux/x86/2004.0, gcc-3.3.5, glibc-2.3.4.20040808-r1, 2.6.10 i686) ================================================================= System uname: 2.6.10 i686 AMD Athlon(tm) XP 2600+ Python: dev-lang/python-2.3.4-r1 [2.3.4 (#1, Feb 8 2005, 20:00:50)] distcc 2.16 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] ccache version 2.3 [disabled] dev-lang/python: 2.3.4-r1 sys-devel/autoconf: 2.59-r6, 2.13 sys-devel/automake: 1.5, 1.7.9-r1, 1.4_p6, 1.9.4, 1.6.3, 1.8.5-r3 sys-devel/binutils: 2.15.92.0.2-r1 sys-devel/libtool: 1.5.10-r4 virtual/os-headers: 2.6.8.1-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-O2 -march=athlon-xp -pipe" CHOST="i686-pc-linux-gnu" CXXFLAGS="-O2 -march=athlon-xp -pipe" FEATURES="autoaddcvs autoconfig buildpkg distlocks sandbox sfperms" MAKEOPTS="-j2" USE="x86 X aalib apm arts avi berkdb bitmap-fonts cdr crypt cups curl directfb dvd dvdr dvdread emboss encode esd f77 fam flac font-server foomaticdb fortran gdbm gif gnome gpm gstreamer gtk gtk2 imagemagick imlib ipv6 java jpeg ldap libg++ libwww mad mikmod mmx motif mozilla mpeg mysql ncurses oggvorbis opengl oss pam pdflib perl png python qt quicktime readline ruby samba sdl slang sse ssl svga tcltk tcpd tiff truetype truetype-fonts type1-fonts xml xml2 xmms xv zlib video_cards_nvidia" Unset: ASFLAGS, CBUILD, CTARGET, LANG, LC_ALL, LDFLAGS, PORTDIR_OVERLAY
Since blackdown-jdk is a binary package, this is one of those cases where revdep-rebuild will not function correctly. The reason is doesn't work is that the linking is broken, however, since it is a binary package, reinistalling just installs the same exact files with the same breakage. The correct way to fix this is to have the blackdown-jdk ebuild fixed to either add alsa-lib as a runtime dependency or to remove the unneeded libraries based upon USE flags. For example, a USE setting of "-alsa" would not install the /opt/blackdown-jdk-1.4.2.01/jre/lib/i386/libjsoundalsa.so library. In the meantime, the revdep-rebuild script in bug# 62644 can be instructed to ignore the /opt/blackdown directory and will not exhibit this behavior.
Added SEARCH_DIRS_MASK="/opt/blackdown-jdk-1.4.2.01" to /etc/make.conf with no effect and I can't find SEARCH_DIRS_MASK in /usr/bin/revdep-rebuild. I have app-portage/gentoolkit-0.2.0 installed. Is there a specific version of gentoolkit needed to do this?
Oh I see, you're talking about the revdep-rebuild attachment in that bug... But about the USE flag, I don't have the alsa USE flag set so the question is how does the lib come there and here is the answer: # rm /opt/blackdown-jdk-1.4.2.01/jre/lib/i386/libjsoundalsa.so # USE="-alsa" emerge --oneshot blackdown-jdk # ls -l /opt/blackdown-jdk-1.4.2.01/jre/lib/i386/libjsoundalsa.so -rwxr-xr-x 1 root root 29056 Mar 2 23:29 /opt/blackdown-jdk-1.4.2.01/jre/lib/i386/libjsoundalsa.so So the USE flag does not have any effect here, libjsoundalsa.so is installed again! Am I missing something???
Yes, the blackdown-jdk ebuild needs to be fixed in order to correctly get rid of this problem. If you use the updated revdep-rebuild and set the SEARCH_DIRS_MASK variable, then that version of the script will not try to repeatedly re-emerge blackdown-jdk.
Correct, that version doesn't want to rebuild anything ATM. I'll see how it works for the future...
*** Bug 76370 has been marked as a duplicate of this bug. ***
*** Bug 91498 has been marked as a duplicate of this bug. ***
*** Bug 91649 has been marked as a duplicate of this bug. ***
Java team, what are your thoughts on this bug. Is this something that we want to fix in the blackdown-jdk ebuild, or do we want to make revdep-rebuild ignore it?
there was already a bug about this. revdep-rebuild should get an option like IGNORE_DIRECTORIES which makes it possible to add for example /opt/blackdown-jdk... to the list of ignored directories. no way to change that in the ebuild. also see #62644 , it's called SEARCH_DIRS_MASK.
There will need to be a fix in the binary ebuilds eventually as revdep-rebuild like functionality is planned to be fully integrated with portage. While it would be possible to have a exclude list there as well, there is not really any good reason for it. If you don't want to delete the file based on a use flag, why not at least hard depend on the actual dependencies?
What can be done in the ebuild is to hard depend on the dependencies of the libraries that are installed, or if it doesn't break the application use a use flag to remove the unneeded libraries. I'm aware of bug #62644 since it is my bug and why I'm asking the question. Right now, I really only would like to see things that look broken, but are not due to the way the application works be masked by revdep-rebuild.
comment #2 is probably the correct solution, however we will need some time to test if there are problems with doeing so. I myself have exams for another 2weeks, and can get on it after them
*** Bug 95310 has been marked as a duplicate of this bug. ***
Created attachment 64396 [details, diff] option to make revdep-rebuild skip binary packages I saw this patch at <http://forums.gentoo.org/viewtopic-t-355143.html>. I haven't tried it out, but it looks promising. The patch adds a command-line option to make revdep-rebuild filter out binary packages from the list of packages to re-emerge.
Please test using app-portage/gentoolkit-0.2.1_pre4. This version includes SEARC_DIRS_MASK.
Created attachment 69770 [details] opera-8.50.ebuild For opera the solution is easy. Just delete the two files before installing, they are not used on gentoo anyway. The attatched ebuild does just that. Opera still works perfectly, including with nescape plugins, and revdep-rebuild no longer tries to rebuild it.
*** Bug 112153 has been marked as a duplicate of this bug. ***
The latest gentoolkit releases in ~arch do not search the blackdown-jdk directories any more so this should be fixed. Thanks for everyone who participated. Another bug should be opened for opera issues, but opera is probably also fixed using the latest gentoolkit. Please reopen if you still have any issues.
Actually, the latest versions will search the directories, unless one of two things happens. The user places the path in SEARCH_DIRS_MASK in /etc/make.conf, or the blackdown-jdk ebuild places a file in /etc/revdep-rebuild containing an appropriate SEARCH_DIRS_MASK.
(In reply to comment #20) > Actually, the latest versions will search the directories, unless one of two > things happens. The user places the path in SEARCH_DIRS_MASK in /etc/make.conf, > or the blackdown-jdk ebuild places a file in /etc/revdep-rebuild containing an > appropriate SEARCH_DIRS_MASK. So it still uses something else than the entries in 99revdep-rebuild? LD_LIBRARY_MASK="libodbcinst.so libodbc.so libjava.so libjvm.so" SEARCH_DIRS="/bin /sbin /usr/bin /usr/sbin /lib* /usr/lib*" SEARCH_DIRS_MASK="" I also run revdep-rebuild and it did not report any problems. blackdown files were also not listed in the revdeprebuild cache files.
revdep-rebuild determines the paths to include/exclude using the following: Note: the variables used are SEARCH_DIRS and SEARCH_DIRS_MASK 1. Read the variable(s) from the running environment 2. Read the variables from /etc/make.conf and append 3. For all files in /etc/revdep-rebuild, read the variables from those files and append 4. For SEARCH_DIRS only, get the PATH from /etc/profile.env and the library directories from /etc/ld.so.conf I added the /etc/revdep-rebuild directory specifically to allow package maintainers to override the default behavior. See http://article.gmane.org/gmane.linux.gentoo.devel/32556/ So, if the maintainer of a binary package wants to override a directory name that is present, he needs to add a file to /etc/revdep-rebuild that contains the appropriate entries. Finally, on my machines revdep-rebuild does search the blackdown-jdk directories, however, because I have all of its dependencies resolved it doesn't complain.
Reopening until the control file is added.
it shouldn't be added see #11
Hi, thank you paul for explaining howto. Due to my limited knowledge with Linux, based on what I currently get: broken /opt/firefox/components/libmozgnome.so (requires libxpcom.so libplds4.so libplc4.so libnspr4.so libgconf-2.so.4 libORBit-2.so.0 liblinc.so.1 libgnomevfs-2.so.0 libbonobo-activation.so.4 libxml2.so.2 libgnome-2.so.0 libbonobo-2.so.0) broken /opt/firefox/components/libnkgnomevfs.so (requires libxpcom.so libplds4.so libplc4.so libnspr4.so libgnomevfs-2.so.0 libbonobo-activation.so.4 libORBit-2.so.0 libxml2.so.2 liblinc.so.1) broken /opt/firefox/components/libnegotiateauth.so (requires libxpcom.so libplds4.so libplc4.so libnspr4.so libgssapi_krb5.so.2) broken /opt/netscape/plugins/mplayerplug-in.so (requires libnspr4.so libplds4.so) done. what should I do? How should I add to /etc/make.conf these LD_LIBRARY_MASK="" SEARCH_DIRS="" SEARCH_DIRS_MASK="" When revdep-revuild finds broken packages, I believe I must fix them by unmerging and emerging them back till all is solved. Now, in extreme cases, like the ones above mentioned, is my last resort adding them to make.conf? Also, what would happen if I am unable to solve broken packages and apply the above solution? Will the application still properly function? Thank you for all these answers/clarifications Spiro
*** Bug 114302 has been marked as a duplicate of this bug. ***
*** Bug 123191 has been marked as a duplicate of this bug. ***
fixed in 8.52
wrong bug, sorry
*** Bug 128296 has been marked as a duplicate of this bug. ***
*** Bug 138824 has been marked as a duplicate of this bug. ***
Well, bug #138824 could easily be fixed by adding the appropriate dependencies for the architectures where >=xorg-x11-7 has been marked stable.
*** Bug 138859 has been marked as a duplicate of this bug. ***
*** Bug 172485 has been marked as a duplicate of this bug. ***
For me, the problem only occurs against sun-jdk-1.4 that, for now, is only required by OOo-2.3.0 . for users: if OOo can not depend on sun-jdk-1.6 , I will rebuild OOo without java, and then remove all 1.4 java things. for maintainers: why cant you apply patch against revdep ?
after emerge -C virtual/jdk-1.4.2 dev-java/sun-jdk-1.4.2.16 my system seems consistent =virtual/jdk-1.4.* is only required for OOo with AMD64, since on AMD64 java 1.5 are broken (see comments in ebuild). So, for me, I have worked around this bug. But, the bug should stay open for AMD64 people. Please, all non AMD64 users try to remove 1.4 like me; even if equerry depends reports it may be required, remove them, and check consistency with emerge -DpNuv world Case closed for me. Bye.
Fixed in blackdown-jdk-1.4.2.03-r16
