interchangeability of RPMs (and .deb files) between distros (was Re: [conspire] public distribution, too choose 1.)

[Daniel Gimpelevich]

On Thu, 20 Jan 2005 14:33:47 -0800, bruce coston wrote:

>       Less obviously, if you will get support from
> CABAL you should seriously consider the .deb package
> system over .rpm. The linuxmafia.com web pages say
> lots about package systems, they make your life easier
> so you probably want one. Currently you will need to
> match the .rpm packages to your ~exact distribution
> while a .deb is a .deb is a .deb unless someone messes
> up. Debian has branches where you can install packages

Nonsense. There's nothing about the .deb format that makes it
distribution-neutral. It's just that because Debian already has
practically every package under the sun, other .deb-based distributions
have always simply used the Debian packages directly, so no matter which
distro it came from, it was made for Debian, and would be therefore be
interchangeable with another package of the same software, also made for
Debian, and typically the packages themselves would be identical, having
ultimately come from the same place. This is not due to the .deb format,
but due to the fact that Debian has all those packages and licensing that
has practically no encumberances. It is perfectly possible for a Linux
distribution to roll their own .deb packages, and there is now a distro
that does that: Ubuntu. Furthermore, the main reason RPMs are considered
distribution-specific is also true of .deb files: The packages install
files at the locations specified by the packagers, which in the case of
packages for your distro (including Debian ones for Debian-based distros)
you want, and in the case of packages not made for your distro (including
using Debian packages on Ubuntu and Ubuntu packages on Debian, as well as
using RPMs on anything) you don't want. Stuff that's not part of your
distro you always want to keep close track of so that #1 no full pathnames
are created that your distro could ever also be created by your distro,
and #2 If you should reinstall your distro, you can recreate your system
as you had it complete with packages not made for it. This is similar in
principle to the need to put stuff you compile yourself into /usr/local.
Interestingly, the RPMs for RealPlayer/HelixPlayer for Linux install most
stuff into /usr/local, with symlinks in /usr/share. This is especially
unfortunate because the /usr/local tree is supposed to have the same
hierarchy as / and /usr, used by all the software in that tree, and those
RPMs create a single directory /usr/local/RealPlayer that also has the
same hierarchy as /, /usr, and /usr/local, which is how /opt is supposed
to work. If you use the installer program instead of the RPM, you get a
choice of installing in /usr/local (the old default), /opt, ~ (the new
default), or elsewhere. The RPMs for IBM Java put everything in /opt. The
disadvantage of the existence of RPMs that put things in these particular
places is that if you blow away your distro but keep /usr/local and /opt,
you've blown away your package database and kept the contents of the
packages, which becomes a problem when you upgrade those packages with
newer RPMs. One way to control where stuff gets put by rpm is to install
from SRPMs instead of RPMs. When you do that, rpm allows you to override
install prefixes, and you may decide to or not to do this, based on the
pros and cons that I have just described and the ones Rick described here:
<http://linuxmafia.com/pipermail/conspire/2005-January/000779.html>
On one final note: The RPM package format and the .deb package format in
no way require Linux in order to be utilized. For example, Fink for MacOSX
uses the same .deb package system that is in no way different except the
packages are not interchangeable with Debian ones in any way.