Re: [gentoo-user] revdep-rebuild reports broken libs, should I worry?
On Wed, 2005-07-06 at 09:49 -0700, Wade Brown wrote: In this specific case, Broken means Binary Package. Binary packages are distributed with all kinds of libraries linked to so that they can minimize the amount of binary packages they need to maintain (e.g. they don't need an eclipse-gnome and an eclipse-nognome package). The program will ideally run as if those features were disabled at compile time, but usually does spit out a few errors on console about missing libraries. Revdep wanting to rebuild binary packages everytime is a known issue, and in newer (still masked?) versions there is a specific directory omission setting to tell it to ignore /opt, and anywhere else there may be binary packages. If it is still masked as I think, then you could just $EDITOR `which revdep-rebuild` and take out /opt from the SEARCH_DIRS variable. Anyway, quick answer, No, your packages are not broken, so no worries. The newer revdep-rebuild is in gentoolkit-0.2.1_pre4, that version is not package masked, but it is currently keyworded with the unstable keywords. If you use the newer revdep-rebuild, the variable that you want to set is SEARCH_DIRS_MASK. Regards, Paul -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] revdep-rebuild reports broken libs, should I worry?
In this specific case, Broken means Binary Package. Binary packages are distributed with all kinds of libraries linked to so that they can minimize the amount of binary packages they need to maintain (e.g. they don't need an eclipse-gnome and an eclipse-nognome package). The program will ideally run as if those features were disabled at compile time, but usually does spit out a few errors on console about missing libraries. Revdep wanting to rebuild binary packages everytime is a known issue, and in newer (still masked?) versions there is a specific directory omission setting to tell it to ignore /opt, and anywhere else there may be binary packages. If it is still masked as I think, then you could just $EDITOR `which revdep-rebuild` and take out /opt from the SEARCH_DIRS variable. Anyway, quick answer, No, your packages are not broken, so no worries. On 7/6/05, Dave Nebinger [EMAIL PROTECTED] wrote: On a run of revdep-rebuild I get the following output: butthead ~ # 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/OpenOffice.org/program/python-core-2.2.2/lib/lib-dynload/_tkinter.so (requires libtk8.4.so libtcl8.4.so) broken /opt/eclipse/plugins/org.eclipse.swt.gtk_3.0.1/os/linux/x86/libswt-gnome-gtk -3063.so (requires libgnomeui-2.so.0 libbonoboui-2.so.0 libgnomecanvas-2.so.0 libgnome-2.so.0 libbonobo-2.so.0 libgconf-2.so.4 libgnomevfs-2.so.0 libbonobo-activation.so.4 libORBit-2.so.0 liblinc.so.1) broken /opt/firefox/components/libmozgnome.so (requires libgconf-2.so.4 libORBit-2.so.0 liblinc.so.1 libgnomevfs-2.so.0 libbonobo-activation.so.4 libgnome-2.so.0 libbonobo-2.so.0) broken /opt/firefox/components/libnkgnomevfs.so (requires libgnomevfs-2.so.0 libbonobo-activation.so.4 libORBit-2.so.0 liblinc.so.1) 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) Dynamic linking on your system is consistent... All done. Now the reason for 'broken' is that I don't have gnome installed, that much I understand. And I'm cool with the fact that revdep-rebuild didn't try to install gnome even though these are marked as broken. The question is, I guess, whether 'broken' has some other meaning than what I'm thinking, and do I need to be worried? -- gentoo-user@gentoo.org mailing list -- gentoo-user@gentoo.org mailing list
