Debian developers communicate with other GNU/Linux distribution creators in an effort to maintain binary compatibility across Linux distributions. Most commercial GNU/Linux products run as well under Debian as they do on the system upon which they were built.
Debian GNU/Linux adheres strictly to the Linux File System Structure (now known as the FHS). However, there is room for interpretation in some of the rules within this standard, so there may be differences between a Debian system and other Linux systems.
Different Linux distributions use different package formats and different package management programs.
A program to unpack a Debian package onto a Linux host that's 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's based on Debian 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 File System Standard.
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 system.
The Linux File System Standard (and therefore
Debian Linux) requires that subdirectories under
entirely under the user's discretion. Therefore, users can unpack
`foreign' packages into this directory, and then manage their configuration,
upgrade, removal individually.
a.out(i.e., QMAGIC or ZMACI) format,
a.outsupport built into it, either directly (CONFIG_BINFMT_AOUT=y) or as a module (CONFIG_BINFMT_AOUT=m). (Debian is distributed with a kernel with support for
a.outbinaries built in directly.)
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.0.0 version of the kernel,
DIRNAME is likely to be
a.outdeveloper's packages, which are
a.outtools ahead of the
ELFtools in your path. That is, execute the command
export PATH=/usr/i486-linuxaout/bin:$PATH(This isn't essential, just advantageous.) If you're only going to do this once, you could execute:
PATH=/usr/i486-linuxaout/bin:$PATH make [target].
a.outX clients, install the
If you have a commercial application in
a.out format, now would
be a good time to ask them to send you an
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/foo, the libraries in
/usr/local/lib, and the configuration files in
If your programs and/or files really must be placed
in some other directory, you could still store them in
and build the appropriate symbolic links from the required location
to its location in
/usr/local, e.g., you could make the link
ln -s /usr/local/bin/foo /usr/bin/foo
In any case, if you obtain a package whose copyright allows redistribution,
you should consider making a Debian package of it, and uploading it for
the Debian system. Guidelines for becoming a package developer are
included in the Debian
doc-debian package; or see the
on-line guide to the package development guidelines.
Debian uses the
terminfo database and the
of terminal interface routes, rather than the
termcap library. Users who are compiling programs that
require some knowledge of the terminal interface should replace references
libtermcap with references to
To support binaries that have already been linked with the
library, and for which you don't have the source,
Debian provides a package called
termcap-compat. This provides
/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
AccelX uses the
termcap library for installation. Debian uses
terminfo database and
ncurses library instead.
To run programs which use the
termcap library, install
termcap-compat; it can be found in the
section in the Debian archives.
Programs that require the
libX11.so.6 library are in
format. To execute them, you need to install the
Yes. But you have to understand the Debian policy with respect to headers.
The Debian C libraries are built with the most recent stable
releases of the
gcc headers. For example, the Debian-1.1 release
uses version 5.2.18 of the headers. This practice contrasts with the Linux
kernel source packages distributed at all Linux FTP archive sites,
which uses even more recent versions of the headers. The kernel headers
distributed with the kernel source are located in
If you need to compile a program with kernel headers that are newer
than those provided by
libc5-dev, then you must add
-I/usr/src/linux/include to your command line when compiling.
This came up at one point, for example, with the packaging of the
automounter daemon (
amd). When new kernels changed some
internals dealing with NFS,
amd needed to know about them. This
required the inclusion of the latest kernel headers.