LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware (https://www.linuxquestions.org/questions/slackware-14/)
-   -   Slack: script to detect orphaned libraries, broken lib links, missing dependencies (https://www.linuxquestions.org/questions/slackware-14/slack-script-to-detect-orphaned-libraries-broken-lib-links-missing-dependencies-794133/)

vdemuth 03-18-2010 09:22 AM

OK, so ran your latest script and it tells me that I have 4,869 orphaned libs, and the resultant --verify log file is 11.6 Mb in size, whilst the verify.log.pkgs would suggest that I have 638 pkgs not installed. FYI, this is a multilib system running AlienBob's KDE4.4.1 build. Looking through the log file would suggest that the missing pkgs are those that were originally installed when Slack13 64bit was first put on my laptop. Any suggestions why this might be and how to correct as it does not seem right somehow.

GrapefruiTgirl 03-18-2010 11:51 AM

First:
Packages shown using --verify are not "not installed" -- but they are detected because *some* file that is included in the slack-package, is not present on the system.
The missing file(s) could be as simple as even a README file, which you knowingly & intentionally deleted from /usr/doc or whatever (in other words, a false positive)

As for this "multi-lib" situation, I have never used multi-lib, and don't plan to try it out since I have no need to. HOWEVER, solely based on the fact that Eric (Alien Bob) probably by now has a really good idea what he's doing when it comes to putting slackware packages together, I would *think* that a properly installed multi-lib system using his packages, *should* be able to be scanned using my script, just the same as a NON-multi-lib system can be scanned; and the results should be meaningful-- provided that you have cleanly replaced/upgraded package ABC with package XYZ, and not simply installed packages on top of one another.

HOWEVER: If by design, the multi-lib packages knowingly & deliberately overwrite or replace pre-existing pieces of another package which is already installed, then the --verify output from my script will indeed contain a lot of mis-information. It would likely help a lot if somebody with a fresh, clean, working multi-lib system, were to try the script and let us know what kind of results THEY get, because going by your results alone, there's nothing to compare it to.

To start fixing your system, I would be starting `pkgtool` and looking for any NON-multi-lib packages that claim to be still installed, but which you know (SHOULD) have been replaced with newer (multi-lib) packages, and remove them. That should trim down the output of the --verify operation.

I can't really say what may or may not be messed up on your machine; I don't know what upgrade method you used, and I don't know how the process of switching to multi-lib went for you. But, cleaning up your system requires manual labor -- there's no automated method of doing it, and if there were, truthfully, I would not really trust it to get the job done correctly. You gotta do it yourself.

This script is intended to provide "a source of information" which you need to evaluate (determine its value) and use as you see fit. But ultimately, YOU have to decide what to do with the information it provides. :)

Sasha

vdemuth 03-18-2010 02:23 PM

Hi Sasha,

Well some more digging and it looks like I have serious problems with my packages database. Not sure how, but at least your script is a starting point to putting it right.

Thanks

Vic

rmjohnso 03-18-2010 07:47 PM

Sasha,

I just tested the new version on my installation, and it looks good on my end.


Matt

bamunds 12-26-2017 06:36 PM

New Multilib issues, how to deal with?
 
I'm trying to clean-up a multilib system. Came across some errors in 32 bit binaries, when running this very helpful script from GrapefruiTgirl for checking libraries and binaries. I've verified with # ldd that the following have missing lib's in /usr/bin/32/ : gnome-keyring-3, gnome-keyring-daemon, smbclient, smbtoture, xscanimage. The missing libraries are not part of compat32 of multilib. I don't know why I would ever run these apps in 32 bit mode, but I would like to clean this up. I've checked this in both Slackware-64 14.1 and 14.2 both with updated multilib and patches. The only thing I haven't done is follow AlienBob's write-up about multilib install for a full conversion from a 32 bit DVD https://docs.slackware.com/slackware:multilib, which really seems like an overkill.

So...

Is this a case of I need to make the missing packages using convertpkg-compat32 from the regular 32 bit DVD?
Or are these safe to ignore since one never runs these programs in 32 bit mode?
Or is this system missing some basic /usr/bin/32/ symlinks?

The curious want to know more about this.. And this thread has previously discussed multilib when created in 13.0. :confused::scratch:

orbea 12-26-2017 07:16 PM

alienBOB's multilib is not a complete system, it just includes most of the stuff needed to run multilib programs in Slackware. In short they are safe to ignore, if you want to deal with them you could either make the missing compat32 packages yourself or since lot of them you probably don't even need you could start removing them and confirming nothing breaks with ldd. There is not really much point to this unless you have extreme hdd space requirements or want to learn more by applying yourself.

bamunds 12-27-2017 12:59 AM

I do like learning about Slackware and the tools to keep it running smoothly and complete. This tool is one that could be invaluable and I'll keep it in my tool pack for future checks.

As for my missing libraries, it appears that for some reason libarchive-compat32 (needed by smbclient) didn't re-install when I did a refresh of the compat32 packages, so that is now installed and resolved. Gnome-keyring compat32's were already installed, but compat32 packages for gcr, gtk+3 and gdk+3 are not part of the package so I'll have to convertpkg-compat32 on the Slackware 14.2 for those. Also compat32 will need to be done for Gimp and python-2.7. That should be all that's needed for now to have a clean answer to the -b option.

Remaining issues are KNOWN and ACCEPTABLE with:
1) orphan library dillo.la and dillo.so which I copied from a local build of claws-mail-git because it is not part of standard builds for claws-mail or dillo.
2) orphan binaries for ESET Nod32 4 Linux which had to be installed with their installer and required this whole multilib install in the first place. ESET Nod32 4 Linux requires both 64 and 32 libraries. Actually maybe I'll try to use src2pkg and see if I can make a proper package.

If I've missed something, or misunderstood what to do. Then please point out my error.

a4z 12-27-2017 02:36 AM

you can also put sbbdep into your toolbox
https://bitbucket.org/a4z/sbbdep/wiki/Home

bamunds 12-27-2017 04:01 PM

Hopefully this will be helpful for other multilib users.

In the end the following Slackware 14.2 (32bit) packages had to be created (#convertpkg-compat32 -i {packagename.txz} -o {packagename-compat32_1ba.txz}) and #installpkg {packagename-compat32_1ba.txz} to make my Slackware64 14.2 Multilib system "clean" (i.e. not show errors with a -b flag):

atk-spi2-atk
at-spi2-core
babl
gcr
gegl
gimp
gtk+3
python-2.7

This was in addition to making sure that all available compat32 packages from AlienBob were installed.

Poprocks 10-13-2019 03:39 PM

I was looking for a script that detects broken library dependencies on a Slackware system for troubleshooting and maintenance purposes.

Just wanted to report that this script still works to this day on a system running -current and multilib.


All times are GMT -5. The time now is 01:18 AM.