The Debian GNU/Linux FAQ
Chapter 3 - Compatibility issues
3.1 On what hardware architectures/systems does Debian GNU/Linux run?
Debian GNU/Linux includes complete source-code for all of the included
programs, so it should work on all systems which are supported by the Linux
kernel; see the Linux
FAQ for details.
The current Debian GNU/Linux release, 3.0, contains a complete, binary
distribution for the following architectures:
i386: this covers PCs based on Intel and compatible processors,
including Intel's 386, 486, Pentium, Pentium Pro, Pentium II (both Klamath and
Celeron), and Pentium III, and most compatible processors by AMD, Cyrix and
m68k: this covers Amigas and ATARIs having a Motorola 680x0 processor
for x>=2; with MMU.
alpha: Compaq/Digital's Alpha systems.
sparc: this covers Sun's SPARC and most UltraSPARC systems.
powerpc: this covers some IBM/Motorola PowerPC machines, including
CHRP, PowerMac and PReP machines.
arm: ARM and StrongARM machines.
mips: SGI's big-endian MIPS systems, Indy and Indigo2;
mipsel: little-endian MIPS machines, Digital DECstations.
The development of binary distributions of Debian for Sparc64 (UltraSPARC
native) and MIPS architectures is currently underway.
For further information on booting, partitioning your drive, enabling PCMCIA
(PC Card) devices and similar issues please follow the instructions given in
the Installation Manual, which is available from our WWW site at http://www.debian.org/releases/stable/i386/install.
3.2 How compatible is Debian with other distributions of Linux?
Debian developers communicate with other Linux distribution creators in an
effort to maintain binary compatibility across Linux distributions. Most
commercial Linux products run as well under Debian as they do on the system
upon which they were built.
Debian GNU/Linux adheres to the Linux Filesystem Hierarchy
Standard. However, there is room for interpretation in some of the
rules within this standard, so there may be slight differences between a Debian
system and other Linux systems.
3.3 How source code compatible is Debian with other Unix systems?
For most applications Linux source code is compatible with other Unix systems.
It supports almost everything that is available in System V Unix systems and
the free and commercial BSD-derived systems. However in the Unix business such
claim has nearly no value because there is no way to prove it. In the software
development area complete compatibility is required instead of compatibility in
"about most" cases. So years ago the need for standards arose, and
nowadays POSIX.1 (IEEE Standard 1003.1-1990) is one of the major standards for
source code compatibility in Unix-like operating systems.
Linux is intended to adhere to POSIX.1, but the POSIX standards cost real money
and the POSIX.1 (and FIPS 151-2) certification is quite expensive; this made it
more difficult for the Linux developers to work on complete POSIX conformance.
The certification costs make it unlikely that Debian will get an official
conformance certification even if it completely passed the validation suite.
(The validation suite is now freely available, so it is expected that more
people will work on POSIX.1 issues.)
Unifix GmbH (Braunschweig, Germany) developed a Linux system that has been
certified to conform to FIPS 151-2 (a superset of POSIX.1). This technology
was available in Unifix' own distribution called Unifix Linux 2.0 and in
3.4 Can I use Debian packages (".deb" files) on my RedHat/Slackware/... Linux system? Can I use RedHat packages (".rpm" files) on my Debian GNU/Linux system?
Different Linux distributions use different package formats and different
package management programs.
You probably can:
A program to unpack a Debian package onto a Linux host that is been built from
a `foreign' distribution is available, and will generally work, in the sense
that files will be unpacked. The converse is probably also true, that is, a
program to unpack a RedHat or Slackware package on a host that is based on
Debian GNU/Linux will probably succeed in unpacking the package and placing
most files in their intended directories. This is largely a consequence of the
existence (and broad adherence to) the Linux Filesystem Hierarchy Standard.
You probably do not want to:
Most package managers write administrative files when they are used to unpack
an archive. These administrative files are generally not standardized.
Therefore, the effect of unpacking a Debian package on a `foreign' host will
have unpredictable (certainly not useful) effects on the package manager on
that system. Likewise, utilities from other distributions might succeed in
unpacking their archives on Debian systems, but will probably cause the Debian
package management system to fail when the time comes to upgrade or remove some
packages, or even simply to report exactly what packages are present on a
A better way:
The Linux File System Standard (and therefore Debian GNU/Linux) requires that
subdirectories under /usr/local/ be entirely under the user's
discretion. Therefore, users can unpack `foreign' packages into this
directory, and then manage their configuration, upgrade and removal
3.5 Is Debian able to run my very old "a.out" programs?
Do you actually still have such a program? :-)
To execute a program whose binary is in a.out (i.e.,
QMAGIC or ZMAGIC) format,
Make sure your kernel has a.out support built into it, either
directly (CONFIG_BINFMT_AOUT=y) or as a module (CONFIG_BINFMT_AOUT=m).
(Debian's kernel-image package contains the module binfmt_aout.)
If your kernel supports a.out binaries by a module, then be sure
that the binfmt_aout module is loaded. You can do this at boot
time by entering the line binfmt_aout into the file
/etc/modules. You can do it from the command line by executing
the command insmod DIRNAME/binfmt_aout.o where
DIRNAME is the name of the directory where the modules that have
been built for the version of the kernel now running are stored. On a system
with the 2.2.17 version of the kernel, DIRNAME is likely to be
install the package libc4, found in one of the releases prior to
release 2.0 (because at that time we removed the package). You might want to
look for an old Debian CD-ROM (Debian 1.3.1 still had this package), or see
on the Internet.
If the program you want to execute is an a.out X client, then
install the xcompat package (see above for availability).
If you have a commercial application in a.out format, now would be
a good time to ask them to send you an ELF upgrade.
3.6 Is Debian able to run my old libc5 programs?
Yes. Just install the required libc5 libraries, from the
oldlibs section (containing old packages included for
compatibility with older applications).
3.7 Can Debian be used to compile libc5 programs?
Yes. Install libc5-altdev and altgcc packages (from
the oldlibs section). You can find the appropriate libc5-compiled
gcc and g++ in directory
/usr/i486-linuxlibc1/bin. Put them in your $PATH variable to get
make and other programs to execute these first.
If you need to compile libc5 X clients, install xlib6 and
Be aware that libc5 environment isn't fully supported by our other packages
3.8 How should I install a non-Debian program?
Files under the directory /usr/local/ are not under the control of
the Debian package management system. Therefore, it is good practice to place
the source code for your program in /usr/local/src/. For example, you might
extract the files for a package named "foo.tar" into the directory
/usr/local/src/foo. After you compile them, place the binaries in
/usr/local/bin/, the libraries in /usr/local/lib/,
and the configuration files in /usr/local/etc/.
If your programs and/or files really must be placed in some other directory,
you could still store them in /usr/local/, and build the
appropriate symbolic links from the required location to its location in
/usr/local/, e.g., you could make the link
3.9 Why do I get "Can't find libX11.so.6" errors when I try to run foo?
This error message could mean that the program is linked against the
libc5 version of the X11 libraries. In this case you need to
install the xlib6 package, from the oldlibs section.
You may get similar error messages referring to libXpm.so.4 file, in which case
you need to install the libc5 version of the XPM library, from the
xpm4.7 package, also in the oldlibs section.
3.10 Why can't I compile programs that require libtermcap?
Debian uses the terminfo database and the ncurses
library of terminal interface routes, rather than the termcap
database and the termcap library. Users who are compiling
programs that require some knowledge of the terminal interface should replace
references to libtermcap with references to
To support binaries that have already been linked with the termcap
library, and for which you do not have the source, Debian provides a package
called termcap-compat. This provides both
libtermcap.so.2 and /etc/termcap. Install this
package if the program fails to run with the error message "can't load
library 'libtermcap.so.2'", or complains about a missing