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 File System Structure. 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. The newest release of this FSSTND standard is now called FHS and we plan to move to it shortly.
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 Lasermoon's Linux-FT.
Different Linux distributions use different package formats and different package management programs.
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 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 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 individually.
Do you still have such a program?
To execute a program whose binary is in a.out
(i.e., QMAGIC or ZMAGIC) format,
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.0.36 version of the kernel,
DIRNAME is likely to be /lib/modules/2.0.36/fs/.
libc4.
By the time Debian 2.0 is released, it is very likely that the
libc4 package had been already removed from the distribution. If
this is the case, you might want to look for an old Debian CD-ROM
(Debian 1.3.1 still had this package).
a.out X client, then
install the xcompat package.
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.
Yes. Just install the required libraries from the oldlibs
section, which are included in Debian 2.0 for compatibility with older
applications.
Yes. In Debian, your system can be fully upgraded to libc6 (including the
development packages), and yet it is possible to develop programs for
libc5. Just install the required -altdev packages. The minimum
set of packages you will need is: altgcc in section
devel and libc5-altdev in section oldlibs.
Then you would have to place the libc5 tools ahead of the normal
tools in your path. That is, execute the command export
PATH=/usr/i486-linuxlibc1/bin:$PATH (This is not essential, just
advantageous.) If you are only going to do this once, you could execute:
PATH=/usr/i486-linuxlibc1/bin:$PATH make [target].
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
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 policy manual.
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 libncurses.
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 /etc/termcap file.
AccelX uses the termcap library for installation. See
about termcap above.
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.
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.2 release
used version 5.4.13 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
/usr/include/linux/include/.
If you need to compile a program with kernel headers that are newer
than those provided by libc6-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.