Difference between revisions of "RedhatDependencies"
| (2 intermediate revisions by one other user not shown) | |||
| Line 1: | Line 1: | ||
=== RPM Dependencies === | === RPM Dependencies === | ||
| − | + | RPMs are an excellent '''package''' format that store a wealth of information about system state and package information. What is often misunderstood is that RPM is '''not''' a dependency ''solver''. RPMs will tell you what other package names, package meta-name or file will solve dependency requirements, but it does not actually try to find or do anything about those dependencies. Tools that work on top of RPM such as up2date (Red Hat), yum (Fedora, others) and apt (from Debian) will solve these dependencies for you and most modern RPM-based Linux distributions will come with (and use by default) these tools. | |
| − | The | + | Where people often run into problems - often called "Dependency Hell" - is when people do [http://catb.org/~esr/jargon/html/W/Wrong-Thing.html The Wrong Thing] with an RPM-based system. These problems of stem from administrators who install packages built for DistroA on a box running DistroB or an RPM from Version X on Version Y. The most notrious problem is attempting to run any package built for SuSE on anything else. Different distributions will have package names, and different versions that are shipped. For libraries such as glibc, this can be very important. Typically, an RPM package will require GLIBC(X.Y.Z), which will be appropriate for it's base distribution. Some ''other'' distrbution may use GLIBC(X.Y.W) instead, so the dependency fails, and the package refuses to install. |
Additionally, different packages may overlap to greater or lesser extents. This will cause a package conflict, and rpm will halt. | Additionally, different packages may overlap to greater or lesser extents. This will cause a package conflict, and rpm will halt. | ||
| Line 14: | Line 14: | ||
=== Managing dependencies === | === Managing dependencies === | ||
| − | + | ==== Dependency Solving via Toolchains ==== | |
| + | As mentioned above, most RPM-based distributions provide native tools to solve dependencies, usually from the particular distribution's mirror sites. Fedora, for example, comes out-of-the-box ready to use yum for all package management tasks. Red Hat uses a semi-proprietary tool called up2date to update it's Enterprise Linux distributions from the Red Hat Network. Other distributions that are RPM-based use yum or apt-get. | ||
| − | + | Yum easily handles mutliple sources of packages, and creating a "repository" to distribute package to clients is relatively easy. A server for up2date is a bit trickier. If you have an [http://rhn.redhat.com RHN] subscription, you ''must'' to use up2date; there is no other way to connect to RedHat's servers. You can run your own server using the [http://current.tigris.org Current] project (Note: This project has been abandonded now that yum is a mainstream tool). Newer versions of up2date also support yum repositories directly. | |
| − | + | ==== Dependency Solving via Compatability Packages ==== | |
| + | Someone trying to install an older RPM on a newer system should also find out if there is a compatability package available that provides the library necessary. compat-libstdc++-296 is a frequent example for compatability with commercial RPMs such as Java and Oracle. Another is openssl096 which provides the older libcrypto.so.1 that many applications still want to use even though it's been long superceeded. | ||
| + | |||
| + | ==== Dependency Solving by Package Rebuilding ==== | ||
| + | Another way to manage dependencies is to make them go away by recompiling or repackaging the RPM. Frequently, this can be accomplished by rebuilding the RPM from the source package. This is almost always works if you come across package built for a similar distribution to what you are actually running (for example, a package built for RedHat Enterprise 3, that you want to run on Fedora Core 4). | ||
[http://rpm.org/RPM-HOWTO/ Building RPMS] is beyond the scope of this article, but the first few steps are usually: | [http://rpm.org/RPM-HOWTO/ Building RPMS] is beyond the scope of this article, but the first few steps are usually: | ||
| Line 33: | Line 38: | ||
===What 'Not' to do === | ===What 'Not' to do === | ||
| − | Do 'NOT' install | + | Do 'NOT' install packages outside of your distribution, unless you fully understand the consequences of your actions. The package developer put the dependencies in there for a reason, ignore them at your peril. |
Latest revision as of 21:27, 7 February 2006
RPM Dependencies
RPMs are an excellent package format that store a wealth of information about system state and package information. What is often misunderstood is that RPM is not a dependency solver. RPMs will tell you what other package names, package meta-name or file will solve dependency requirements, but it does not actually try to find or do anything about those dependencies. Tools that work on top of RPM such as up2date (Red Hat), yum (Fedora, others) and apt (from Debian) will solve these dependencies for you and most modern RPM-based Linux distributions will come with (and use by default) these tools.
Where people often run into problems - often called "Dependency Hell" - is when people do The Wrong Thing with an RPM-based system. These problems of stem from administrators who install packages built for DistroA on a box running DistroB or an RPM from Version X on Version Y. The most notrious problem is attempting to run any package built for SuSE on anything else. Different distributions will have package names, and different versions that are shipped. For libraries such as glibc, this can be very important. Typically, an RPM package will require GLIBC(X.Y.Z), which will be appropriate for it's base distribution. Some other distrbution may use GLIBC(X.Y.W) instead, so the dependency fails, and the package refuses to install.
Additionally, different packages may overlap to greater or lesser extents. This will cause a package conflict, and rpm will halt.
It actually gets worse...
At this point, the admin will discover the --force option to rpm, and proceed to break things. At best, the package will simply install, but refuse to run and take up disk space. At worst, it will overwrite critical libraries, binaries, and config files. This tends to render a system useless.
Managing dependencies
Dependency Solving via Toolchains
As mentioned above, most RPM-based distributions provide native tools to solve dependencies, usually from the particular distribution's mirror sites. Fedora, for example, comes out-of-the-box ready to use yum for all package management tasks. Red Hat uses a semi-proprietary tool called up2date to update it's Enterprise Linux distributions from the Red Hat Network. Other distributions that are RPM-based use yum or apt-get.
Yum easily handles mutliple sources of packages, and creating a "repository" to distribute package to clients is relatively easy. A server for up2date is a bit trickier. If you have an RHN subscription, you must to use up2date; there is no other way to connect to RedHat's servers. You can run your own server using the Current project (Note: This project has been abandonded now that yum is a mainstream tool). Newer versions of up2date also support yum repositories directly.
Dependency Solving via Compatability Packages
Someone trying to install an older RPM on a newer system should also find out if there is a compatability package available that provides the library necessary. compat-libstdc++-296 is a frequent example for compatability with commercial RPMs such as Java and Oracle. Another is openssl096 which provides the older libcrypto.so.1 that many applications still want to use even though it's been long superceeded.
Dependency Solving by Package Rebuilding
Another way to manage dependencies is to make them go away by recompiling or repackaging the RPM. Frequently, this can be accomplished by rebuilding the RPM from the source package. This is almost always works if you come across package built for a similar distribution to what you are actually running (for example, a package built for RedHat Enterprise 3, that you want to run on Fedora Core 4).
Building RPMS is beyond the scope of this article, but the first few steps are usually:
- Obtain the source rpm. It will be named:
package-version.src.rpm - Run:
rpmbuild --rebuild package-version.src.rpm
It should be obvious if it works or fails. Other links that are useful for package building:
- http://sial.org/howto/rpm/
- http://www.novell.com/coolsolutions/feature/11793.html
- http://dag.wieers.com/howto/rpm/
What 'Not' to do
Do 'NOT' install packages outside of your distribution, unless you fully understand the consequences of your actions. The package developer put the dependencies in there for a reason, ignore them at your peril.
