Difference between revisions of "RedhatDependencies"
| Line 14: | Line 14: | ||
=== Managing dependencies === | === Managing dependencies === | ||
| − | There are | + | There are several solutions to dealing with dependency problems. While Debian's <code>apt-get</code> program is frequently praised for ease of use, and cited as "better" than <code>rpm</code>, this is actually an unfair comparison. A better match would be to compare <code>dpkg</code> to <code>rpm</code>, and <code>apt-get</code> to RedHat's <code>up2date</code> program, or <code>[http://linux.duke.edu/projects/yum/ yum]</code> (used by Fedora and many other distributions). And just to get in a cheap shot, the apt-get source code is ''ugly''. |
Both up2date and yum handle dependencies, just like 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. Newer versions of up2date also support yum repositories directly. | Both up2date and yum handle dependencies, just like 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. Newer versions of up2date also support yum repositories directly. | ||
Revision as of 20:26, 5 October 2005
RPM Dependencies
RPM dependencies are the bane of all RedHat distributions, and it's various ill-begotten spawn.
The problem stems from administrators who install packages built for DistroA on a box running DistroB. 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
There are several solutions to dealing with dependency problems. While Debian's apt-get program is frequently praised for ease of use, and cited as "better" than rpm, this is actually an unfair comparison. A better match would be to compare dpkg to rpm, and apt-get to RedHat's up2date program, or yum (used by Fedora and many other distributions). And just to get in a cheap shot, the apt-get source code is ugly.
Both up2date and yum handle dependencies, just like 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. Newer versions of up2date also support yum repositories directly.
A last way to manage dependencies is to make them go away. 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.
