Jose Yamut, Jr

Fond of +rw but seldom has time 4 both. 😎😋🤖

How To linux

getting away with RPM dependecies

yes i’m still old school. most of the time i download the source, compile, and make an RPM package out of it. i prefer it this way. like when i do major upgrades short of distro upgrades. i download the RPM packages first, then install it manually.

the thing with this method is that you get into a lot of RPM package dependency issues. so you end up looking for an update for another group of packages. good if there are updates. what if there weren’t any? or sometimes the supposedly updated package needs a dynamic library file that’s older than the one you got in your system. do you downgrade it just to upgrade something? now that would seem to defeat the purpose of updating your software, wouldn’t it?

so here’s the not-so-secret secret: you don’t really have to follow what the error message says after you tried installing a RPM. if you believe that your system is very up-to-date and you can’t go around the dependency issue, then by all means force the installation. use the –nodeps option. if you get a warning saying that the installation will replace some files but you are confident that installing this RPM will do more good than harm, then use the –force option.

there are certain situations when the newer version of an app you’re trying to install needs a .so file, for example (this is always the case in my experience), that is older than the one you have on your sytem. after forcing an install, you find to your dismay that the app crashes. it is always good to note the errors or warnings that RPM tells you. so if you did, then good for you! you may have yet saved yourself from banging your head on the wall.

  1. let’s say you got libFoobar.so.1 in your system and the app you’re installing needs libFoobar.so.0. make a symbolic link to this existing library file and name it with the .so.0 extension as required by the app. most of the time it will work. why? unless the Linux version in your box is really, really old (like hey you’re still using kernel 2.4 for a desktop Linux?!) or your distro is already at version 10 while you’re still at 8 (and you suddenly wanted to use Amarok 1.4.3), there’s a good chance that these revisions are so minor that the 2 library file versions are basically same. or the app just exits when it can’t find a particular library. hence the crash.
  2. if symbolic linking won’t work, try to get a copy of this file and put it into your system. the best way is to download the RPM package of this file. then extract the needed file(s) from the package. don’t know how to extract from RPM? simple.
    rpm2cpio libFoobar-0.0-0.i686.rpm | cpio -id
    (read the manual on both of these commands if you have questions)
  3. if all else fails then here’s my last tip: start banging your head on the wall. scream afterwards while pulling your hair at the same time.

but really this was what i did with my current KDE version. 3.5.4 to be exact. it’s 98% stable as of yet, except for that occasional hiccup. that is where the 2% goes.

Similar Posts:

yes i’m still old school. most of the time i download the source, compile, and make an RPM package out of it. i prefer it this way. like when i do major upgrades short of distro upgrades. i download the RPM packages first, then install it manually. the thing with this method is that you…