The Debian GNU/Linux FAQ - Compatibility issues

[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ 13 ] [ 14 ] [ 15 ] [ 16 ] [ next ]

# The Debian GNU/Linux FAQ
Chapter 4 - Compatibility issues

## 4.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, 7, contains a complete, binary distribution for the following architectures:

- amd64: this covers systems based on AMD 64bit CPUs with AMD64 extension and all Intel CPUs with EM64T extension, and a common 64bit userspace.

- armel: little-endian ARM machines.

- armhf: an alternative to armel for ARMv7 machines with hard-float.

- i386: this covers systems 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 others.

- ia64: Intel IA-64 ("Itanium") computers.

- mips: SGI's big-endian MIPS systems, Indy and Indigo2; mipsel: little-endian MIPS machines, Digital DECstations.

- powerpc: this covers some IBM/Motorola PowerPC machines, including the Apple Macintosh PowerMac models, and the CHRP and PReP open architecture machines.

- s390: IBM S/390 mainframe systems.

- s390x: 64-bit port for IBM System z machines intended to replace s390.

- sparc: this covers Sun's SPARC and most UltraSPARC systems, and some of their successors in the sun4 architectures

The development of binary distributions of Debian for armhf (for ARM boards and devices with a floating-point unit), arv32 (for Atmel's 32-bit RISC architecture), m32 (for 32-bit RISC microprocessor of Renesas Technology), s390x (for the 64-bit userland for IBM System z mainframes), and sh (for Hitachi SuperH processors) is currently underway.

Support for the m68k architecture was dropped in the Etch (Debian 4.0) release, because it did not meet the criteria set by the Debian Release Managers. This architecture covers Amigas and ATARIs having a Motorola 680x0 processor for x>=2; with MMU. However, the port is still active and available for installation even if not a part of this official stable release and might be reactivated for future releases.

Support for the hppa (Hewlett-Packard's PA-RISC machines) and alpha (Compaq/Digital's Alpha systems) were dropped in the Squeeze (Debian 6.0) release for similar reasons. The arm was dropped too in this release, as it was superseded by the armel arquitecture.

For more information on the available ports see the `ports pages at the website`.

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/installmanual`.

## 4.2 What kernels does Debian GNU/Linux run?

Debian provides a complete, binary distribution for the following operating system kernels:

- FreeBSD: provided through the kfreebsd-amd64 and kfreebsd-i386 ports, for 64-bit PCs and 32-bit PCs respectively. These ports were first released in Debian 6.0 Squeeze as a technology preview.

In addition to these, work is in progress on the following adaptations:

- avr32, port to Atmel's 32-bit RISC architecture,

- hurd-i386 a port for 32-bit PC. This port will use GNU Hurd, the new operating system being put together by the GNU group,

- sh, port to Hitachi SuperH processors.

There were attempts to port the distribution to the NetBSD kernel, providing netbsd-i386 (for 32-bit PCs) and netbsd-alpha (for Alpha machines) but these ports were never released and are currently abandoned.

For more information on the available ports see the `ports pages at the website`.

## 4.3 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.

Debian GNU/Linux supports software developed for the `Linux Standard Base`. The LSB is a specification for allowing the same binary package to be used on multiple distributions. The Debian Etch release is Certified for LSB Release 3.1, see the `Linux Foundation Certification webpage`. Discussion and coordination of efforts towards ensuring Debian meets the requirements of the Linux Standard Base is taking place on the `debian-lsb mailing list`.

## 4.4 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 Lasermoon's Linux-FT.

## 4.5 Can I use Debian packages (".deb" files) on my Red Hat/Slackware/... Linux system? Can I use Red Hat 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 Red Hat 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. The `Alien` package is used to convert between different package formats.

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 system.

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 individually.

## 4.6 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

         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 (see What other documentation exists on and for a Debian system?, Section 12.1).

## 4.7 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.

The low-level `terminfo` library has been split out from the general `ncurses library`, making a new package called `libtinfo5`. `libncurses` is linked to `libtinfo`, so 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, you will have to find the library source and compile it yourself. Debian used to provide a package called termcap-compat which contained both `libtermcap.so.2` and `/etc/termcap`, but this was removed from the distribution in 2005.

## 4.8 Why can't I install AccelX?

AccelX uses the `termcap` library for installation. See Why can't I compile programs that require libtermcap?, Section 4.7 above.

[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ 13 ] [ 14 ] [ 15 ] [ 16 ] [ next ]

The Debian GNU/Linux FAQ