Very Computer

I wonder if the RPMs found in rpmfind.net, for example, which are shown to
be for a particular instalation, say Mandrake, or Conectiva, if these are
usable by other instalations like Red Hat 8.0 (which I have).

Thanks

Carlos

Quote:> I wonder if the RPMs found in rpmfind.net, for example, which are shown to
> be for a particular instalation, say Mandrake, or Conectiva, if these are
> usable by other instalations like Red Hat 8.0 (which I have).

In general, no.  Most rpms are distro-specific.

-- Rex

They often require recompilation from SRPM and modification of the .spec
files. Different distributions call the same software different things,
such as "gd" vs. "libgd", and may not include components that are
automatically part of the other (such as the "radius" software for
compiling nagios-plugins). Even the RPM specfile command sets may be
different. "%make" from Mandrake, or the "idgroups" command?

Quote:> I wonder if the RPMs found in rpmfind.net, for example, which are shown to
> be for a particular instalation, say Mandrake, or Conectiva, if these are
> usable by other instalations like Red Hat 8.0 (which I have).

Yes, but with some major caveats. Most importantly, most RPMs are built
assuming particular support library versions. If your distribution has
different (particularly older) support libraries, chances are a binary
RPM won't work. You can often (but not always) work around this problem
by obtaining the source RPM and recompiling it on your system. (Use "rpm
--rebuild file-version.src.rpm" or replace "rpm" with "rpmbuild" on some
systems. The rebuilt RPM should then appear somewhere in the /usr/src
directory, in an RPM directory tree.) Sometimes an RPM will have a
dependency to a package of a particular name, but the equivalent
functionality is in another package on your distribution, you'll get a
failed dependencies error. Using "--nodeps" at install time will overcome
this problem, but you should only try this if you're sure the equivalent
functionality is present on your system. If the RPM is for a server,
there may also be server startup issues caused by differing SysV startup
script locations or format, but you can work around those problems by
replacing the startup scripts or starting the server in a local startup
script.

Overall, for non-server programs, I'd guess I have about an 80% success
rate installing binary RPMs across distributions, provided I try binaries
for distributions that are older than the one I'm running. For most of
the rest, rebuilding from a source RPM does the trick. For servers, the
success rate is about the same, except that manually changing the startup
procedure is often required.

--

http://www.rodsbooks.com
Author of books on Linux, FreeBSD, and networking