The Debian GNU/Linux FAQ ------------------------ Authors are listed at Debian FAQ Authors version CVS, 17 June 2006 ------------------------------------------------------------------------------- Abstract -------- This document answers questions frequently asked about Debian GNU/Linux. Copyright Notice ---------------- Copyright (C) 1996-2005 by Software in the Public Interest, portions copyright (C) 2004, 2005, 2006 Kamaraju Kusumanchi Permission is granted to make and distribute verbatim copies of this document provided the copyright notice and this permission notice are preserved on all copies. Permission is granted to copy and distribute modified versions of this document under the conditions for verbatim copying, provided that the entire resulting derived work is distributed under the terms of a permission notice identical to this one. Permission is granted to copy and distribute translations of this document into another language, under the above conditions for modified versions, except that this permission notice may be included in translations approved by the Free Software Foundation instead of in the original English. ------------------------------------------------------------------------------- Contents -------- 1. Definitions and overview 1.1. What is this FAQ? 1.2. What is Debian GNU/Linux? 1.3. OK, now I know what Debian is... what is Linux?! 1.4. Does Debian just do GNU/Linux? 1.5. What is the difference between Debian GNU/Linux and other Linux distributions? Why should I choose Debian over some other distribution? 1.6. How does the Debian project fit in or compare with the Free Software Foundation's GNU project? 1.7. How does one pronounce Debian and what does this word mean? 2. Getting and installing Debian GNU/Linux 2.1. What is the latest version of Debian? 2.2. Are there package upgrades in `stable'? 2.3. Where/how can I get the Debian installation disks? 2.4. How do I install the Debian from CD-ROMs? 2.5. Why does the official stable released CD-ROM contain symlinks for `frozen' and `unstable'? I thought this CD contains just `stable'! 2.6. I have my own CD-writer, are there CD images available somewhere? 2.7. Can I install it from a pile of floppy disks? 2.8. Can I get and install Debian directly from a remote Internet site? 3. Choosing a Debian distribution 3.1. Which Debian distribution (stable/testing/unstable) is better for me? 3.1.1. You asked me to install stable, but in stable so and so hardware is not detected/working. What should I do? 3.1.2. Will there be different different versions of packages in different distributions? 3.1.3. The stable distributions really contains outdated packages. Just look at Kde, Gnome, Xorg or even the kernel. They are very old. Why is it so? 3.1.4. If I were to decide to change to another distribution, Can I do that? 3.1.5. Could you tell me whether to install testing or unstable? 3.1.6. You are talking about testing being broken. What do you mean by that? 3.1.7. Why is it that testing could be broken for months? Wont the fixes introduced in unstable flow directly down into testing? 3.1.8. From an administrator's point of view, Which distribution requires more attention? 3.1.9. What happens when a new release is made? 3.1.10. I have a working Desktop/cluster with Debian installed. How do I know which distribution I am running? 3.1.11. I am currently tracking stable. Can I change to testing or unstable? If so, How? 3.1.12. I am currently tracking testing (lenny). What will happen when a release is made? Will I still be tracking testing or will my machine be running the new stable distribution? 3.1.13. I am still confused. What did you say I should install? 3.2. But what about Knoppix, Linex, Ubuntu, and others? 3.2.1. I know that Knoppix/Linex/Ubuntu/... is Debian-based. So after installing it on the hard disk, can I use 'apt' package tools on it? 3.2.2. I installed Knoppix/Linex/Ubuntu/... on my hard disk. Now I have a problem. What should I do? 3.2.3. I'm using Knoppix/Linex/Ubuntu/... and now I want to use Debian. How do I migrate? 4. Compatibility issues 4.1. On what hardware architectures/systems does Debian GNU/Linux run? 4.2. How compatible is Debian with other distributions of Linux? 4.3. How source code compatible is Debian with other Unix systems? 4.4. 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? 4.5. Is Debian able to run my old libc5 programs? 4.6. Can Debian be used to compile libc5 programs? 4.7. How should I install a non-Debian program? 4.8. Why can't I compile programs that require libtermcap? 4.9. Why can't I install AccelX? 4.10. Why do my old XFree 2.1 Motif applications crash? 5. Software available in the Debian system 5.1. What types of applications and development software are available for Debian GNU/Linux? 5.2. Who wrote all that software? 5.3. How can I get a current list of programs that have been packaged for Debian? 5.4. How can I install a developer's environment to build packages? 5.5. What is missing from Debian GNU/Linux? 5.6. Why do I get "ld: cannot find -lfoo" messages when compiling programs? Why aren't there any libfoo.so files in Debian library packages? 5.7. (How) Does Debian support Java? 5.8. How can I check that I am using a Debian system, and what version is it? 5.9. How does Debian support non-English languages? 5.10. What about the US export regulation limitations? 5.11. Where is pine? 5.12. Where is qmail/ezmlm/djbdns? 6. The Debian FTP archives 6.1. What are all those directories at the Debian FTP archives? 6.2. How many Debian distributions are there in the `dists' directory? 6.3. What are all those names like slink, potato, etc.? 6.3.1. Which other codenames have been used in the past? 6.3.2. Where do these codenames come from? 6.4. What about "sid"? 6.5. What does the stable directory contain? 6.6. What does the testing directory contain? 6.6.1. What about "testing"? How is it `frozen'? 6.7. What does the unstable directory contain? 6.8. What are all those directories inside `dists/stable/main'? 6.9. Where is the source code? 6.10. What's in the `pool' directory? 6.11. What is "incoming"? 6.12. How do I set up my own apt-able repository? 7. Basics of the Debian package management system 7.1. What is a Debian package? 7.2. What is the format of a Debian binary package? 7.3. Why are Debian package file names so long? 7.4. What is a Debian control file? 7.5. What is a Debian conffile? 7.6. What is a Debian preinst, postinst, prerm, and postrm script? 7.7. What is an _Essential_ _Required_, _Important_, _Standard_, _Optional_, or _Extra_ package? 7.8. What is a Virtual Package? 7.9. What is meant by saying that a package _Depends_, _Recommends_, _Suggests_, _Conflicts_, _Replaces_ or _Provides_ another package? 7.10. What is meant by Pre-Depends? 7.11. What is meant by _unknown_, _install_, _remove_ _purge_ and _hold_ in the package status? 7.12. How do I put a package on hold? 7.13. How do I install a source package? 7.14. How do I build binary packages from a source package? 7.15. How do I create Debian packages myself? 8. The Debian package management tools 8.1. What programs does Debian provide for managing its packages? 8.1.1. dpkg 8.1.2. APT 8.1.3. aptitude 8.1.4. tasksel 8.1.5. dselect 8.1.6. Other package management tools 8.2. Debian claims to be able to update a running program; how is this accomplished? 8.3. How can I tell what packages are already installed on a Debian system? 8.4. How to display the files of a package installed? 8.5. How can I find out what package produced a particular file? 8.6. Why doesn't get `foo-data' removed when I uninstall `foo'? How do I make sure old unused library-packages get purged? 9. Keeping your Debian system up-to-date 9.1. How can I keep my Debian system current? 9.1.1. aptitude 9.1.2. apt-get, dselect and apt-cdrom 9.1.3. aptitude 9.1.4. dpkg-ftp 9.1.5. mirror 9.1.6. dpkg-mountable 9.2. Must I go into single user mode in order to upgrade a package? 9.3. Do I have to keep all those .deb archive files on my disk? 9.4. How can I keep a log of the packages I added to the system? I'd like to know when which package upgrades and removals have occured! 9.5. Can I automatically update the system? 9.6. I have several machines how can I download the updates only one time? 10. Debian and the kernel 10.1. Can I install and compile a kernel without some Debian-specific tweaking? 10.2. What tools does Debian provide to build custom kernels? 10.3. How can I make a custom boot floppy? 10.4. What special provisions does Debian provide to deal with modules? 10.5. Can I safely de-install an old kernel package, and if so, how? 11. Customizing your installation of Debian GNU/Linux 11.1. How can I ensure that all programs use the same paper size? 11.2. How can I provide access to hardware peripherals, without compromising security? 11.3. How do I load a console font on startup the Debian way? 11.4. How can I configure an X11 program's application defaults? 11.5. Every distribution seems to have a different boot-up method. Tell me about Debian's. 11.6. It looks as if Debian does not use `rc.local' to customize the boot process; what facilities are provided? 11.7. How does the package management system deal with packages that contain configuration files for other packages? 11.8. How do I override a file installed by a package, so that a different version can be used instead? 11.9. How can I have my locally-built package included in the list of available packages that the package management system knows about? 11.10. Some users like mawk, others like gawk; some like vim, others like elvis; some like trn, others like tin; how does Debian support diversity? 12. Getting support for Debian GNU/Linux 12.1. What other documentation exists on and for a Debian system? 12.2. Are there any on-line resources for discussing Debian? 12.2.1. Mailing lists 12.2.2. Maintainers 12.2.3. Usenet newsgroups 12.3. Is there a quick way to search for information on Debian GNU/Linux? 12.4. Are there logs of known bugs? 12.5. How do I report a bug in Debian? 13. Contributing to the Debian Project 13.1. How can I become a Debian software developer? 13.2. How can I contribute resources to the Debian project? 13.3. How can I contribute financially to the Debian project? 13.3.1. Software in the Public Interest 13.3.2. Free Software Foundation 14. Redistributing Debian GNU/Linux in a commercial product 14.1. Can I make and sell Debian CDs? 14.2. Can Debian be packaged with non-free software? 14.3. I am making a special Linux distribution for a "vertical market". Can I use Debian GNU/Linux for the guts of a Linux system and add my own applications on top of it? 14.4. Can I put my commercial program in a Debian "package" so that it installs effortlessly on any Debian system? 15. Changes expected in the next major release of Debian 15.1. Increased security 15.2. Extended support for non-English users 15.3. More architectures 15.4. More kernels 16. General information about the FAQ 16.1. Authors 16.2. Feedback 16.3. Availability 16.4. Document format ------------------------------------------------------------------------------- 1. Definitions and overview --------------------------- 1.1. What is this FAQ? ---------------------- This document gives frequently asked questions (with their answers!) about the Debian distribution (Debian GNU/Linux and others) and about the Debian project. If applicable, pointers to other documentation will be given: we won't quote large parts of external documentation in this document. You'll find out that some answers assume some knowledge of Unix-like operating systems. We'll try to assume as little prior knowledge as possible: answers to general beginners questions will be kept simple. If you can't find what you're looking for in this FAQ, be sure to check out Section 12.1, `What other documentation exists on and for a Debian system?'. If even that doesn't help, refer to Section 16.2, `Feedback'. 1.2. What is Debian GNU/Linux? ------------------------------ Debian GNU/Linux is a particular _distribution_ of the Linux operating system, and numerous packages that run on it. Debian GNU/Linux is: * _full featured_: Debian includes more than 18200 software packages at present. Users can select which packages to install; Debian provides a tool for this purpose. You can find a list and descriptions of the packages currently available in Debian at any of the Debian mirror sites (http://www.debian.org/distrib/ftplist). * _free to use and redistribute_: There is no consortium membership or payment required to participate in its distribution and development. All packages that are formally part of Debian GNU/Linux are free to redistribute, usually under terms specified by the GNU General Public License. The Debian FTP archives also carry approximately 560 software packages (in the `non-free' and `contrib' sections), which are distributable under specific terms included with each package. * _dynamic_: With about 1060 volunteers constantly contributing new and improved code, Debian is evolving rapidly. The FTP archives are updated twice every day. Most Linux users run a specific _distribution_ of Linux, like Debian GNU/Linux. However, in principle, users could obtain the Linux kernel via the Internet or from elsewhere, and compile it themselves. They could then obtain source code for many applications in the same way, compile the programs, then install them into their systems. For complicated programs, this process can be not only time-consuming but error-prone. To avoid it, users often choose to obtain the operating system and the application packages from one of the Linux distributors. What distinguishes the various Linux distributors are the software, protocols, and practices they use for packaging, installing, and tracking applications packages on users' systems, combined with installation and maintenance tools, documentation, and other services. Debian GNU/Linux is the result of a volunteer effort to create a free, high-quality Unix-compatible operating system, complete with a suite of applications. The idea of a free Unix-like system originates from the GNU project, and many of the applications that make Debian GNU/Linux so useful were developed by the GNU project. For Debian, free has the GNUish meaning (see the Debian Free Software Guidelines (http://www.debian.org/social_contract#guidelines)). When we speak of free software, we are referring to freedom, not price. Free software means that you have the freedom to distribute copies of free software, that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs; and that you know you can do these things. The Debian Project was created by Ian Murdock in 1993, initially under the sponsorship of the Free Software Foundation's GNU project. Today, Debian's developers think of it as a direct descendent of the GNU project. Although Debian GNU/Linux itself is free software, it is a base upon which value-added Linux distributions can be built. By providing a reliable, full-featured base system, Debian provides Linux users with increased compatibility, and allows Linux distribution creators to eliminate duplication of effort and focus on the things that make their distribution special. See Section 14.3, `I am making a special Linux distribution for a "vertical market". Can I use Debian GNU/Linux for the guts of a Linux system and add my own applications on top of it?' for more information. 1.3. OK, now I know what Debian is... what is Linux?! ----------------------------------------------------- In short, Linux is the kernel of a Unix-like operating system. It was originally designed for 386 (and better) PCs; today Linux also runs on a dozen of other systems. Linux is written by Linus Torvalds and many computer scientists around the world. Besides its kernel, a "Linux" system usually has: * a file system that follows the Linux Filesystem Hierarchy Standard http://www.pathname.com/fhs/. * a wide range of Unix utilities, many of which have been developed by the GNU project and the Free Software Foundation. The combination of the Linux kernel, the file system, the GNU and FSF utilities, and the other utilities are designed to achieve compliance with the POSIX (IEEE 1003.1) standard; see Section 4.3, `How source code compatible is Debian with other Unix systems?'. For more information about Linux, see What is Linux (http://www.linux.org/info/) by Linux Online (http://www.linux.org/). 1.4. Does Debian just do GNU/Linux? ----------------------------------- Currently, Debian is only available for Linux, but with Debian GNU/Hurd and Debian on BSD kernels, we have started to offer non-Linux-based OSes as a development, server and desktop platform, too. However, these non-linux ports are not officially released yet. The oldest porting effort is Debian GNU/Hurd. The Hurd is a set of servers running on top of the GNU Mach microkernel. Together they build the base for the GNU operating system. Please see http://www.gnu.org/software/hurd/ for more information about the GNU/Hurd in general, and http://www.debian.org/ports/hurd/ for more information about Debian GNU/Hurd. A second effort is the port to a BSD kernel. People are working with both the NetBSD and the FreeBSD kernels. See http://www.debian.org/ports/#nonlinux for more information about these non-linux ports. 1.5. What is the difference between Debian GNU/Linux and other Linux distributions? Why should I choose Debian over some other distribution? ---------------------------------------------------------------------------- These key features distinguish Debian from other Linux distributions: Freedom: As stated in the Debian Social Contract (http://www.debian.org/social_contract), Debian will remain 100% free. Debian is very strict about shipping truly free software. The guidelines used to determine if a work is "free" are provided in The Debian Free Software (http://www.debian.org/social_contract#guidelines). The Debian package maintenance system: The entire system, or any individual component of it, can be upgraded in place without reformatting, without losing custom configuration files, and (in most cases) without rebooting the system. Most Linux distributions available today have some kind of package maintenance system; the Debian package maintenance system is unique and particularly robust (see Chapter 7, `Basics of the Debian package management system'). Open development: Whereas other Linux distributions are developed by individuals, small, closed groups, or commercial vendors, Debian is the only major Linux distribution that is being developed cooperatively by many individuals through the Internet, in the same spirit as Linux and other free software. More than 1060 volunteer package maintainers are working on over 18200 packages and improving Debian GNU/Linux. The Debian developers contribute to the project not by writing new applications (in most cases), but by packaging existing software according to the standards of the project, by communicating bug reports to upstream developers, and by providing user support. See also additional information on how to become a contributor in Section 13.1, `How can I become a Debian software developer?'. The Universal Operating System: Debian comes with more than 18200 packages (http://packages.debian.org/stable/) and runs on 11 architectures (http://www.debian.org/ports/). This is far more than is available for any other GNU/Linux distribution. See Section 5.1, `What types of applications and development software are available for Debian GNU/Linux?' for an overview of the provided software and see Section 4.1, `On what hardware architectures/systems does Debian GNU/Linux run?' for a description of the supported hardware platforms. The Bug Tracking System: The geographical dispersion of the Debian developers required sophisticated tools and quick communication of bugs and bug-fixes to accelerate the development of the system. Users are encouraged to send bugs in a formal style, which are quickly accessible by WWW archives or via e-mail. See additional information in this FAQ on the management of the bug log in Section 12.4, `Are there logs of known bugs?'. The Debian Policy: Debian has an extensive specification of our standards of quality, the Debian Policy. This document defines the qualities and standards to which we hold Debian packages. For additional information about this, please see our web page about reasons to choose Debian (http://www.debian.org/intro/why_debian). 1.6. How does the Debian project fit in or compare with the Free Software Foundation's GNU project? ---------------------------------------------------------------------------- The Debian system builds on the ideals of free software first championed by the Free Software Foundation (http://www.gnu.org/) and in particular by Richard Stallman (http://www.stallman.org/). FSF's powerful system development tools, utilities, and applications are also a key part of the Debian system. The Debian Project is a separate entity from the FSF, however we communicate regularly and cooperate on various projects. The FSF explicitly requested that we call our system "Debian GNU/Linux", and we are happy to comply with that request. The FSF's long-standing objective is to develop a new operating system called GNU, based on Hurd (http://www.gnu.org/software/hurd/). Debian is working with FSF on this system, called Debian GNU/Hurd (http://www.debian.org/ports/hurd/). 1.7. How does one pronounce Debian and what does this word mean? ---------------------------------------------------------------- The project name is pronounced Deb'-ee-en, with a short e in Deb, and emphasis on the first syllable. This word is a contraction of the names of Debra and Ian Murdock, who founded the project. (Dictionaries seem to offer some ambiguity in the pronunciation of Ian (!), but Ian prefers ee'-en.) ------------------------------------------------------------------------------- 2. Getting and installing Debian GNU/Linux ------------------------------------------ The official document giving installation instructions is the Debian GNU/Linux Installation Guide (http://www.debian.org/releases/stable/installmanual). We'll give some additional notes about getting and installing Debian GNU/Linux here. 2.1. What is the latest version of Debian? ------------------------------------------ Currently there are three versions of Debian GNU/Linux: _release 4.0, a.k.a. the `stable' distribution or etch_ This is stable and well tested software, it changes if major security or usability fixes are incorporated. _the `testing' distribution, currently called lenny_ This is where packages that will be released as the next `stable' are placed; they've had some testing in unstable but they may not be completely fit for release yet. This distribution is updated more often than `stable', but not more often than `unstable'. _the `unstable' distribution_ This is the version currently under development; it is updated continuously. You can retrieve packages from the `unstable' archive on any Debian FTP site and use them to upgrade your system at any time, but you may not expect the system to be as usable or as stable as before - that's why it's called `_unstable_'! Please see Section 6.2, `How many Debian distributions are there in the `dists' directory?' for more information. 2.2. Are there package upgrades in `stable'? -------------------------------------------- No new functionality is added to the stable release. Once a Debian version is released and tagged `stable' it will only get security updates. That is, only packages for which a security vulnerability has been found after the release will be upgraded. All the security updates are served through security.debian.org (ftp://security.debian.org). Security updates serve one purpose: to supply a fix for a security vulnerability. They are not a method for sneaking additional changes into the stable release without going through normal point release procedure. Consequently, fixes for packages with security issues will not upgrade the software. The Debian Security Team will backport the necessary fixes to the version of the software distributed in `stable' instead. For more information related to security support please read the Security FAQ (http://www.debian.org/security/faq) or the Debian Security Manual (http://www.debian.org/doc/manuals/securing-debian-howto/). 2.3. Where/how can I get the Debian installation disks? ------------------------------------------------------- You can get the installation disks by downloading the appropriate files from one of the Debian mirrors (http://www.debian.org/mirror/list). The installation system files are separated in subdirectories of `dists/stable/main' directory, and the names of these subdirectories correspond to your architecture like this: `disks-' ( is "i386", "sparc", etc, check the site for an exact list). In each of these architecture subdirectories there can be several directories, each for a version of the installation system, and the currently used one is in the `current' directory (that's a symbolic link). See the `README.txt' file in that directory for further instructions. 2.4. How do I install the Debian from CD-ROMs? ---------------------------------------------- Linux supports the ISO 9660 (CD-ROM) file system with Rock Ridge extensions (formerly known as "High Sierra"). Several vendors (http://www.debian.org/CD/vendors/) provide Debian GNU/Linux in this format. Warning: When installing from CD-ROM, it is usually not a good idea to choose dselect's `cdrom' access method. This method is usually very slow. The `mountable' and `apt' methods, for example, are much better for installing from CD-ROM (see Section 9.1.6, `dpkg-mountable' and Section 9.1.2, `apt-get, dselect and apt-cdrom'). 2.5. Why does the official stable released CD-ROM contain symlinks for `frozen' and `unstable'? I thought this CD contains just `stable'! ---------------------------------------------------------------------------- Official Debian CD images indeed contain symlinks like: /dists/frozen -> etch/ /dists/stable -> etch/ /dists/testing -> etch/ /dists/unstable -> etch/ so that they work when your sources.list has an entry like deb cdrom:[]/ unstable main [...] . The fact these symlinks are present does _not_ mean the image is `unstable' or `testing' or anything. Read the CD label in `/.disk/info' to find out which Debian version it contains. This information is also present in `/README.txt' on the CD. Read http://www.debian.org/releases/ to find out what the current `stable' and `testing' releases are. 2.6. I have my own CD-writer, are there CD images available somewhere? ---------------------------------------------------------------------- Yes. To make it easier for CD vendors to provide high quality disks, we provide the Official CD images (http://cdimage.debian.org/). 2.7. Can I install it from a pile of floppy disks? -------------------------------------------------- First of all, a warning: whole Debian GNU/Linux is way too large to be installed from media as small as a standard 1.44MB floppy disk - you may not find installing from floppies a very pleasant experience. Copy the Debian packages onto formatted floppy disks. Either a DOS, the native Linux "ext2", or the "minix" format will do; one just has to use a mount command appropriate to the floppy being used. Using floppy disks has these complications: * Short MS-DOS file names: If you are trying to place Debian package files onto MS-DOS formatted disks, you will find that their names are generally too long, and do not conform to the MS-DOS 8.3 filename limitation. To overcome this, you would have to use VFAT formatted disks, since VFAT supports longer file names. * Large file sizes: Some packages are larger than 1.44 MBytes, and will not fit onto a single floppy disk. To solve this problem, use the dpkg-split tool (see Section 8.1.6.2, `dpkg-split'), available in the `tools' directory on Debian mirrors (http://www.debian.org/mirror/list). You must have support in the kernel for floppy disks in order to read and write to floppy disk; most kernels come with floppy drive support included in them. To mount a floppy disk under the mount point `/floppy' (a directory which should have been created during installation), use: * mount -t msdos /dev/fd0 /floppy/ if the floppy disk is in drive A: and has an MS-DOS file system, * mount -t msdos /dev/fd1 /floppy/ if the floppy disk is in drive B: and has an MS-DOS file system, * mount -t ext2 /dev/fd0 /floppy/ if the floppy disk is in drive A: and has an ext2 (i.e., a normal Linux) file system. 2.8. Can I get and install Debian directly from a remote Internet site? ----------------------------------------------------------------------- Yes. You can boot the Debian installation system from a set of files you can download from our FTP site and its mirrors. You can download a small CD image file, create a bootable CD from it, install the basic system from it and the rest over the network. For more information please see http://www.debian.org/CD/netinst/. You can also download even smaller floppy disk image files, create bootable diskettes from them, start the installation procedure and get the rest of Debian over the network. For more information, please see http://www.debian.org/distrib/floppyinst. ------------------------------------------------------------------------------- 3. Choosing a Debian distribution --------------------------------- There are many different Debian distributions. Choosing the proper Debian distribution is an important decission. This section covers some information useful for users that want to make the choice best suited for their system and also answers possible questions that might be arising during the process. It does not deal with "why you should choose Debian" but rather "which distribution of Debian". For more information on the available distributions read Section 6.2, `How many Debian distributions are there in the `dists' directory?'. 3.1. Which Debian distribution (stable/testing/unstable) is better for me? -------------------------------------------------------------------------- The answer is a bit complicated. It really depends on what you intend to do. One solution would be to ask a friend who runs Debian. But that does not mean that you cannot make an independent decision. In fact, you should be able to decide once you complete reading this chapter. * If security or stability are at all important for you: install stable. period. This is the most preferred way. * If you are a new user installing to a desktop machine, start with stable. Some of the software is quite old, but it's the least buggy environment to work in. You can easily switch to the more modern unstable once you are a little more confident. * If you are a desktop user with some experience in Linux and does not mind facing the odd bug now and then, use unstable. It has all the latest and greatest software, and bugs are usually fixed swiftly. * If you are running a server, especially one that has strong stability requirements or is exposed to the Internet, install stable. This is by far the strongest and safest choice. The following questions (hopefully) provide more detail on these choices. After reading this whole FAQ, if you still could not make a decision, stick with the stable distribution. 3.1.1. You asked me to install stable, but in stable so and so hardware is not detected/working. What should I do? ---------------------------------------------------------------------------- Try to search the web using a search engine and see if someone else is able to get it working in stable. Most of the hardware should work fine with stable. But if you have some state-of-the-art, cutting edge hardware, it might not work with stable. If this is the case, you might want to install/upgrade to unstable. For laptops, http://www.linux-on-laptops.com/ is a very good website to see if someone else is able to get it to work under Linux. The website is not specific to Debian, but is nevertheless a tremendous resource. I am not aware of any such website for desktops. Another option would be to ask in the debian-user mailing list by sending an email to debian-user@lists.debian.org . Messages can be posted to the list even without subscribing. The archives can be read through http://lists.debian.org/debian-user/ Information regarding subscribing to the list can be found at the location of archives. You are strongly encourage to post your questions on the mailing-list than on irc (http://www.debian.org/support). The mailing-list messages are archived, so solution to your problem can help others with the same issue. 3.1.2. Will there be different different versions of packages in different distributions? ---------------------------------------------------------------------------- Yes. Unstable has the most recent (latest) versions. But the packages in unstable are not well tested and might have bugs. On the other hand, stable contains old versions of packages. But this package is well tested and is less likely to have any bugs. The packages in testing fall between these two extremes. 3.1.3. The stable distributions really contains outdated packages. Just look at Kde, Gnome, Xorg or even the kernel. They are very old. Why is it so? ---------------------------------------------------------------------------- Well, you might be correct. The age of the packages at stable depends on when the last release was made. Since there is typically over 1 year between releases you might find that stable contains old versions of packages. However, they have been tested in and out. One can confidently say that the packages do not have any known severe bugs, security holes etc., in them. The packages in stable integrate seamlessly with other stable packages. These characteristics are very important for production servers which have to work 24 hours a day, 7 days a week. On the other hand, packages in testing or unstable can have hidden bugs, security holes etc., Moreover, some packages in testing and unstable might not be working as intended. Usually people working on a single desktop prefer having the latest and most modern set of packages. Unstable is the solution for this group of people. As you can see, stability and novelty are two opposing ends of the spectrum. If stability is required: install stable distribution. If you want to work with the latest packages, then install unstable. 3.1.4. If I were to decide to change to another distribution, Can I do that? ---------------------------------------------------------------------------- Yes, but it is a one way process. You can go from stable --> testing --> unstable. But the reverse direction is not "possible". So better be sure if you are planning to install/upgrade to unstable. Actually, if you are an expert and if you are willing to spend some time and if you are real careful and if you know what you are doing, then it might be possible to go from unstable to testing and then to stable. The installer scripts are not designed to do that. So in the process, your configuration files might be lost and.... 3.1.5. Could you tell me whether to install testing or unstable? ---------------------------------------------------------------- This is a rather subjective issue. There is no perfect answer but only a "wise guess" could be made while deciding between unstable and testing. My personal order of preference is Stable, Unstable and Testing. The issue is like this: * Stable is rock solid. It does not break. * Testing breaks less often than Unstable. But when it breaks, it takes a long time for things to get rectified. Sometimes this could be days and it could be months at times. * Unstable changes a lot, and it can break at any point. However, fixes get rectified in many occasions in a couple of days and it always has the latest releases of software packaged for Debian. But there are times when tracking testing would be beneficial as opposed to unstable. The author such situation due to the gcc transition from gcc3 to gcc4. He was trying to install the `labplot' package on a machine tracking unstable and it could not be installed in unstable as some of its dependencies have undergone gcc4 transition and some have not. But the package in testing was installable on a testing machine as the gcc4 transitioned packages had not "trickled down" to testing. 3.1.6. You are talking about testing being broken. What do you mean by that? ---------------------------------------------------------------------------- Sometimes, a package might not be installable through package management tools. Sometimes, a package might not be available at all, maybe it was (temporarily) removed due to bugs or unmet dependencies. Sometimes, a package installs but does not behave in the proper way. When these things happen, the distribution is said to be broken (at least for this package). 3.1.7. Why is it that testing could be broken for months? Wont the fixes introduced in unstable flow directly down into testing? ---------------------------------------------------------------------------- The bug fixes and improvements introduced in the unstable distribution trickle down to testing after a certain number of days. Let's say this threshold is 10 days. The packages in unstable go into testing only when there are no RC-bugs reported against them. If there is a RC-bug filed against a package in unstable, it will not go into testing after the 10 days. The idea is that, if the package has any problems, it would be discovered by people using unstable and will be fixed before it enters testing. This keeps the testing in an usable state for most period of the time. Overall a brilliant concept, if you ask me. But things are alwasy not so simple. Consider the following situation: * Imagine you are interested in package XYZ. * Let's assume that on June 10, the version in testing is XYZ-3.6 and in unstable it is XYZ-3.7 * After 10 days, XYZ-3.7 from unstable migrates into testing. * So on June 20, both testing and unstable have XYZ-3.7 in their repositories. * Let's say, The user of testing distribution sees that a new XYZ package is available and updates his XYZ-3.6 to XYZ-3.7 * Now on June 25, someone using testing or unstable discovers an RC bug in XYZ-3.7 and files it in the BTS. * The maintainer of XYZ fixes this bug and uploads it to unstable say on June 30. Here it is assumed that it takes 5 days for the maintainer to fix the bug and upload the new version. The number 5 should not be taken literally. It could be less or more, depending upon the severity of the RC-bug at hand. * This new version in unstable, XYZ-3.8 is scheduled to enter testing on July 10th. * But on July 5th some other person, discovers another RC-bug in XYZ-3.8 * Let's say the maintainer of XYZ fixes this new RC-bug and uploads new version of XYZ after 5 days. * So on July 10, testing has XYZ-3.7 while unstable has XYZ-3.9 * This new version XYZ-3.9 is now rescheduled to enter testing on July 20th. * Now since you are running testing, and since XYZ-3.7 is buggy, you could probably use XYZ only after July 20th. That is you essentially ended up with a broken XYZ for about one month. The situation can get much more complicated, if say, XYZ depends on 4 other packages. This could in turn lead to unusable testing distribution for months. The above scenario which is artificially created by me, can occur in the real life. But such occurrences are rare. 3.1.8. From an administrator's point of view, Which distribution requires more attention? ---------------------------------------------------------------------------- One of the main reasons many people chose Debian over other Linux distributions is that it requires very little administration. People want a system that just works. In general one can say that, stable requires very little maintenance while testing and unstable require constant maintenance from the administrator. If you are running stable, all you need to worry about is, keeping track of security updates. If you are running either testing or unstable it is a good idea to be aware of the new bugs discovered in the installed packages, new bugfixes/features introduced etc. 3.1.9. What happens when a new release is made? ----------------------------------------------- This question will not help you in choosing a Debian distribution. But sooner or later you will face this question. The stable distribution is currently etch; The next stable distribution will be called as lenny. Let's consider the particular case as to what happens when lenny is released as the new stable version. * oldstable = sarge; stable = etch; testing = lenny; unstable = sid * Unstable is always referred to as sid irrespective of whether a release is made or not. * packages constantly migrate from sid to testing (i.e. lenny). But packages in stable (i.e. etch) remain the same except for security updates. * after sometime testing becomes frozen. But it will still be called testing. At this point no new packages from unstable can migrate to testing unless they include release-critical (RC) bug fixes. * When testing is frozen, all the new bugfixes introduced, have to be manualy checked by the members of the release team. This is done to ensure that there wont be any unknown severe problems in the frozen testing. * RC bugs in 'frozen testing' are reduced to zero. * The 'frozen testing' with no rc-bugs will be released as the new stable version. In our example, this new stable release will be called as lenny. * At this stage oldstable = etch, stable = lenny. The contents of stable and 'frozen testing' are same at this point. * A new testing is forked from the current stable. * Packages start coming down from sid to testing and the Debian community will be working towards making the next stable release. 3.1.10. I have a working Desktop/cluster with Debian installed. How do I know which distribution I am running? ---------------------------------------------------------------------------- In most situations it is very easy to figure this out. Take a look at the `/etc/apt/sources.list' file. There will be an entry similar to this: deb http://ftp.us.debian.org/debian/ unstable main contrib The third field ('unstable' in the above example) indicates the Debian distribution the system is currently tracking. You can also use `lsb_release' (available in the `lsb-release' package). If you run this program in an unstable system you will get: $ lsb_release -a LSB Version: core-2.0-noarch:core-3.0-noarch:core-3.1-noarch:core-2.0-ia32:core-3.0-ia32:core-3.1-ia32 Distributor ID: Debian Description: Debian GNU/Linux unstable (sid) Release: unstable Codename: sid However, this is always not that easy. Some systems might have `sources.list' files with multiple entries corresponding to different distributions. This could happen if the administrator is tracking different packages from different Debian distributions. This is frequently referred to as apt-pinning. These systems might run a mixture of distributions. 3.1.11. I am currently tracking stable. Can I change to testing or unstable? If so, How? ---------------------------------------------------------------------------- If you are currently running stable, then in the `/etc/apt/sources.list' file the third field will be either etch or stable. You need to change this to the distribution you want to run. If you want to run testing, then change the third field of `/etc/apt/sources.list' to testing. If you want to run unstable, then change the third field to unstable. Currently testing is called lenny. So, if you change the third field of `/etc/apt/sources.list' to lenny, then also you will be running testing. But when lenny becomes stable, you will still be tracking lenny. Unstable is always called Sid. So if you change the third field of `/etc/apt/sources.list' to sid, then you will be tracking unstable. Currently Debian offers security updates for testing but not for unstable, as fixes in unstable are directly made to the main archive. So if you are running unstable make sure that you remove the lines relating to security updates in `/etc/apt/sources.list'. If there is a release notes document available for the distribution you are upgrading to (even though it has not yet been released) it would be wise to review it, as it might provide information on how you should upgrade to it. Nevertheless, once you make the above changes, you can run `aptitude update' and then install the packages that you want. Notice that installing a package from a different distribution might automatically upgrade half of your system. If you install individual packages you will end up with a system running mixed distributions. It might be best in some situations to just fully upgrade to the new distribution running `apt-get dist-upgrade', `aptitude safe-upgrade' or `aptitude full-upgrade'. Read apt's and aptitude's manual pages for more information. 3.1.12. I am currently tracking testing (lenny). What will happen when a release is made? Will I still be tracking testing or will my machine be running the new stable distribution? ---------------------------------------------------------------------------- It depends on the entries in the `/etc/apt/sources.list' file. If you are currently tracking testing, these entries are similar to either: deb http://ftp.us.debian.org/debian/ testing main or deb http://ftp.us.debian.org/debian/ lenny main If the third field in `/etc/apt/sources.list' is 'testing' then you will be tracking testing even after a release is made. So after lenny is released, you will be running a new Debian distribution which will have a different codename. Changes might not be apparent at first but will be evident as soon as new packages from unstable go over to the testing distribution. But if the third field contains 'lenny' then you will be tracking stable (since lenny will then be the new stable distribution). 3.1.13. I am still confused. What did you say I should install? --------------------------------------------------------------- If unsure, the best bet would be stable distribution. 3.2. But what about Knoppix, Linex, Ubuntu, and others? ------------------------------------------------------- They are not Debian; they are _Debian based_. Though there are many similarities and commonalities between them, there are also crucial differences. All these distributions have their own merits and are suited to some specific set of users. For more information, read the information of software distributions based on Debian (http://www.debian.org/misc/children-distros) available at the Debian website. 3.2.1. I know that Knoppix/Linex/Ubuntu/... is Debian-based. So after installing it on the hard disk, can I use 'apt' package tools on it? ---------------------------------------------------------------------------- These distributions are Debian based. But they are not Debian. You will be still able to use apt package tools by pointing the `/etc/apt/sources.list' file to these distributions' repositories. But then you are not running Debian, you are running a different distribution. They are not the same. In most situations if you stick with one distribution you should use that and not mix packages from other distributions. Many common breakages arise due to people running a distribution and trying to install Debian packages from other distributions. The fact that they use the same formatting and name (.deb) does not make them inmediately compatible. For example, Knoppix is a Linux distribution designed to be booted as a live CD where as Debian is designed to be installed on hard-disk. Knoppix is great if you want to know whether a particular hardware works, or if you want to experience how a linux system 'feels' etc., Knoppix is good for demonstration purposes while Debian is designed to run 24/7. Moreover the number of packages available, the number of architectures supported by Debian are far more greater than that of Knoppix. If you want Debian, it is best to install Debian from the get-go. Although it is possible to install Debian through other distributions, such as Knoppix, the procedure calls for expertise. If you are reading this FAQ, I would assume that you are new to both Debian and Knoppix. In that case, save yourself a lot of trouble later and install Debian right at the beginning. 3.2.2. I installed Knoppix/Linex/Ubuntu/... on my hard disk. Now I have a problem. What should I do? ---------------------------------------------------------------------------- You are advised not to use the Debian forums (either mailing lists or IRC) for help as people might advise you thinking that you are running a Debian system and the "fixes" they provide might not be suited to what you are running. They might even worsen the problem you are facing. Use the forums of the specific distribution you are using first. If you do not get help or the help you get does not fix your problem you might want to try asking in Debian forums, but keep the advise of the previous paragraph in mind. 3.2.3. I'm using Knoppix/Linex/Ubuntu/... and now I want to use Debian. How do I migrate? ---------------------------------------------------------------------------- Consider the change from a Debian-based distribution to Debian just like a change from one operating system to another one. You should make a backup of all your date and reinstall the operating system from scratch. You should not attempt to "upgrade" to Debian using the package management tools as you might end up with an unusable system. If all your user data (i.e. your `/home') is under a separate partition migrating to Debian is actually quite simple, you just have to tell the installation system to mount (but not reformat) that partition when reinstalling. Making backups of your data, as well as your previous system's configuration (i.e. `/etc/' and, maybe, `/var/') is still encouraged. ------------------------------------------------------------------------------- 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 (http://en.tldp.org/FAQ/Linux-FAQ/intro.html#DOES-LINUX-RUN-ON-MY-COMPUTER) for details. The current Debian GNU/Linux release, 4.0, contains a complete, binary distribution for the following architectures: _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. _amd64_: this covers systems based on AMD 64bit CPUs with AMD64 extension and all Intel CPUs with EM64T extension, and a common 64bit userspace. _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. _hppa_: Hewlett-Packard's PA-RISC machines (712, C3000, L2000, A500). _ia64_: Intel IA-64 ("Itanium") computers. _s390_: IBM S/390 mainframe systems. The development of binary distributions of Debian for Sparc64 (UltraSPARC native) architectures is currently underway. Support for the _m68k_ architecture was dropped in this 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. For more information on the available ports see the ports pages at the website (http://www.debian.org/ports/). 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. 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 (http://www.pathname.com/fhs/). 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 (http://www.linuxbase.org/). The LSB is a specification for allowing the same binary package to be used on multiple distributions. Packages for the Debian Etch release must not conflict with requirements of the LSB, v1.3. As of this writing, Debian GNU/Linux is not formally LSB-certified. However, some Debian derived distributions are. 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 (http://lists.debian.org/debian-lsb/). 4.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 Lasermoon's Linux-FT. 4.4. 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 (http://packages.debian.org/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.5. 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). 4.6. 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. Be aware that libc5 environment isn't fully supported by our other packages anymore. 4.7. 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 Section 12.1, `What other documentation exists on and for a Debian system?'). 4.8. 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 `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. 4.9. Why can't I install AccelX? -------------------------------- AccelX uses the `termcap' library for installation. See Section 4.8, `Why can't I compile programs that require libtermcap?' above. 4.10. Why do my old XFree 2.1 Motif applications crash? ------------------------------------------------------- You need to install the `motifnls' package, which provides the XFree-2.1 configuration files needed to allow Motif applications compiled under XFree-2.1 to run under XFree-3.1. Without these files, some Motif applications compiled on other machines (such as Netscape) may crash when attempting to copy or paste from or to a text field, and may also exhibit other problems. ------------------------------------------------------------------------------- 5. Software available in the Debian system ------------------------------------------ 5.1. What types of applications and development software are available for Debian GNU/Linux? ---------------------------------------------------------------------------- Like most Linux distributions, Debian GNU/Linux provides: * the major GNU applications for software development, file manipulation, and text processing, including gcc, g++, make, texinfo, Emacs, the Bash shell and numerous upgraded Unix utilities, * Perl, Python, Tcl/Tk and various related programs, modules and libraries for each of them, * TeX (LaTeX) and Lyx, dvips, Ghostscript, * the Xorg windowing system, which provides a networked graphical user interface for Linux, and countless X applications including the GNOME, KDE and Xfce desktop environments. * a full suite of networking applications, including servers for Internet protocols such as HTTP (WWW), FTP, NNTP (news), SMTP and POP (mail) and DNS (name servers); relational databases like PostgreSQL, MySQL; also provided are web browsers including the various Mozilla products [1], * a complete set of office applications, including the OpenOffice.org productivity suite, Gnumeric and other spreadsheets, WYSIWYG editors, calendars. More than 18040 packages, ranging from news servers and readers to sound support, FAX programs, database and spreadsheet programs, image processing programs, communications, net, and mail utilities, Web servers, and even ham-radio programs are included in the distribution. Another 560 software suites are available as Debian packages, but are not formally part of Debian due to license restrictions. [1] These have been, however, rebranded and are provided with different names due to trademark issues 5.2. Who wrote all that software? --------------------------------- For each package the _authors_ of the program(s) are credited in the file `/usr/share/doc/PACKAGE/copyright', where PACKAGE is to be substituted with the package's name. _Maintainers_ who package this software for the Debian GNU/Linux system are listed in the Debian control file (see Section 7.4, `What is a Debian control file?') that comes with each package. The Debian changelog, in `/usr/share/doc/PACKAGE/changelog.Debian.gz', mentions the people who've worked on the Debian packaging too. 5.3. How can I get a current list of programs that have been packaged for Debian? ---------------------------------------------------------------------------- A complete list is available from any of the Debian mirrors (http://www.debian.org/distrib/ftplist), in the file `indices/Maintainers'. That file includes the package names and the names and e-mails of their respective maintainers. The WWW interface to the Debian packages (http://packages.debian.org/) conveniently summarizes the packages in each of about thirty "sections" of the Debian archive. 5.4. How can I install a developer's environment to build packages? ------------------------------------------------------------------- If you want to build packages in your Debian system you will need to have a basic development environment, including a C/C++ compiler and some other essential packages. In order to install this environment you just need to install the `build-essential'. This package is a meta-package or place-holder package which depends on the standard development tools one needs to build a Debian package. Some software can, however, need additional software to be rebuilt, including library headers or additional tools such as `autoconf' or `gettext'. Debian provides many of the tools needed to build other software as Debian packages. Finding which software is precisely required can be tricky, however, unless you are planning on rebuilding Debian packages. This last task is rather easy to do, as official packages have to include a list of the additional software (besides the packages in `build-essential') needed to build the pacakge, this is known as `Build-Dependencies'. To install all the packages needed to build a given source package and then build said source package you can just run: # apt-get build-dep # apt-get source --build Notice that if you want to build the Linux kernels distributed by Debian you will want to install also the `kernel-package' package. For more information see Section 10.2, `What tools does Debian provide to build custom kernels?'. 5.5. What is missing from Debian GNU/Linux? ------------------------------------------- A list of packages which are still needed to be packaged for Debian exists, the Work-Needing and Prospective Packages list (http://www.debian.org/devel/wnpp/). For more details about adding the missing things, see Section 13.1, `How can I become a Debian software developer?'. 5.6. Why do I get "ld: cannot find -lfoo" messages when compiling programs? Why aren't there any libfoo.so files in Debian library packages? ---------------------------------------------------------------------------- Debian Policy requires that such symbolic links (to libfoo.so.x.y.z or similar) are placed in separate, development packages. Those packages are usually named libfoo-dev or libfooX-dev (presuming the library package is named libfooX, and X is a whole number). 5.7. (How) Does Debian support Java? ------------------------------------ Several _free_ implementations of Java technology are available as Debian packages, providing both Java Development Kits as well as Runtime Environments. You can write, debug and run Java programs using Debian. Running a Java applet requires a web browser with the capability to recognize and execute them. Several web browsers available in Debian, such as Mozilla or Konqueror, support Java plug-ins that enable running Java applets within them. Please refer to the Debian Java FAQ (http://www.debian.org/doc/manuals/debian-java-faq/) for more information. 5.8. How can I check that I am using a Debian system, and what version is it? ---------------------------------------------------------------------------- In order to make sure that your system has been installed from the real Debian base disks check for the existence of `/etc/debian_version' file, which contains a single one-line entry giving the version number of the release, as defined by the package `base-files'. The existence of the program `dpkg' shows that you should be able to install Debian packages on your system, but as the program has been ported to many other operating systems and architectures, this is no longer a reliable method of determining is a system Debian GNU/Linux. Users should be aware, however, that the Debian system consists of many parts, each of which can be updated (almost) independently. Each Debian "release" contains well defined and unchanging contents. Updates are separately available. For a one-line description of the installation status of package `foo', use the command `dpkg --list foo'. To view versions of all installed packages, run: dpkg -l For a more verbose description, use: dpkg --status foo 5.9. How does Debian support non-English languages? --------------------------------------------------- * Debian GNU/Linux is distributed with keymaps for nearly two dozen keyboards, and with utilities (in the `kbd' package) to install, view, and modify the tables. The installation prompts the user to specify the keyboard he will use. * Vast majority of the software we packaged supports entering non-US-ASCII characters used in other Latin languages (e.g. ISO-8859-1 or ISO-8859-2), and a number of programs support multi-byte languages such as Japanese or Chinese. * Currently, support for German-, Spanish-, Finnish-, French-, Hungarian-, Italian-, Japanese-, Korean-, Dutch-, Polish-, Portuguese-, Russian-, Turkish-, and Chinese-language manual pages is provided through the `manpages-LANG' packages (where LANG is the two-letter ISO country code). To access an NLS manual page, the user must set the shell LC_MESSAGES variable to the appropriate string. For example, in the case of the Italian-language manual pages, LC_MESSAGES needs to be set to 'italian'. The `man' program will then search for Italian manual pages under `/usr/share/man/it/'. 5.10. What about the US export regulation limitations? ------------------------------------------------------ US laws placed restrictions on the export of defense articles, which includes some types of cryptographic software. PGP and ssh, among others, fall into this category. For the _sarge_ release packages in this archive were moved to the main archive (or to _non-free_, if applicable) due to the US relaxing its regulations on the export of cryptography. To prevent anyone from taking unnecessary legal risks, certain Debian GNU/Linux packages were only available from a non-US site ftp://non-US.debian.org/debian-non-US/, with numerous mirror sites all of which are also outside of the US, see ftp://non-US.debian.org/debian-non-US/README.non-US for a full list. These sites still exist (for the benefit of users of _woody_) but its contents are no longer supported and are considered obsolete. Please remove any mentions to non-US from your sources in your `/etc/apt/sources.list' configuration file. 5.11. Where is pine? -------------------- Due to its restrictive license, it's in the non-free area. Moreover, since license does not even allow modified binaries to be distributed, you have to compile it yourself from the source and the Debian patches. The source package name is `pine'. You can use the `pine-tracker' package to be notified about when you need to upgrade. Note that there are many replacements for both pine and pico, such as `mutt' and `nano', that are located in the main section. 5.12. Where is qmail/ezmlm/djbdns? ---------------------------------- Dan J. Bernstein distributes all software he has written (http://cr.yp.to/software.html) with a restrictive license, consequently, it's in the non-free area. Since the license he uses does not allow modified binaries to be distributed, you have to compile it yourself from the source and the Debian patches to obtain a binary package you can install in your Debian GNU/Linux system. The source package names are `qmail-src', `ezmlm-src' and `djbdns-installer', respectively. For `qmail' you need to install `qmail-src' first and then run `build-qmail' to build the Debian package. You also need to do install the `ucspi-tcp-src' package to get ucspi-tcp, which `qmail' depends on. Dan J. Bernstein maintains a FAQ from distributors (http://cr.yp.to/distributors.html) page if you are interested in reading his reasons (one of which is Cross-platform compatibility (http://cr.yp.to/compatibility.html)) ------------------------------------------------------------------------------- 6. The Debian FTP archives -------------------------- 6.1. What are all those directories at the Debian FTP archives? --------------------------------------------------------------- The software that has been packaged for Debian GNU/Linux is available in one of several directory trees on each Debian mirror site. The `dists' directory is short for "distributions", and it is the canonical way to access the currently available Debian releases (and pre-releases). The `pool' directory contains the actual packages, see Section 6.10, `What's in the `pool' directory?'. There are the following supplementary directories: _/tools/_: DOS utilities for creating boot disks, partitioning your disk drive, compressing/decompressing files, and booting Linux. _/doc/_: The basic Debian documentation, such as the FAQ, the bug reporting system instructions, etc. _/indices/_: The Maintainers file and the override files. _/project/_: mostly developer-only materials, such as: _project/experimental/_: This directory contains packages and tools which are still being developed, and are still in the alpha testing stage. Users shouldn't be using packages from here, because they can be dangerous and harmful even for the most experienced people. 6.2. How many Debian distributions are there in the `dists' directory? ---------------------------------------------------------------------- There are three distributions, the "stable" distribution, the "testing" distribution, and the "unstable" distribution. The "testing" distribution is sometimes `frozen' (see Section 6.6.1, `What about "testing"? How is it `frozen'?'). 6.3. What are all those names like slink, potato, etc.? ------------------------------------------------------- They are just "codenames". When a Debian distribution is in the development stage, it has no version number but a codename. The purpose of these codenames is to make easier the mirroring of the Debian distributions (if a real directory like `unstable' suddenly changed its name to `stable', a lot of stuff would have to be needlessly downloaded again). Currently, `stable' is a symbolic link to `etch' (i.e. Debian GNU/Linux 4.0) and `testing' is a symbolic link to `lenny'. This means that `etch' is the current stable distribution and `lenny' is the current testing distribution. `unstable' is a permanent symbolic link to `sid', as `sid' is always the unstable distribution (see Section 6.4, `What about "sid"?'). 6.3.1. Which other codenames have been used in the past? -------------------------------------------------------- Other codenames that have been already used are: `buzz' for release 1.1, `rex' for release 1.2, `bo' for releases 1.3.x, `hamm' for release 2.0, `slink' for release 2.1, `potato' for release 2.2, `woody' for release 3.0, `sarge' for release 3.1, and `etch' for release 4.0 6.3.2. Where do these codenames come from? ------------------------------------------ So far they have been characters taken from the movie "Toy Story" by Pixar. * _buzz_ (Buzz Lightyear) was the spaceman, * _rex_ was the tyrannosaurus, * _bo_ (Bo Peep) was the girl who took care of the sheep, * _hamm_ was the piggy bank, * _slink_ (Slinky Dog (R)) was the toy dog, * _potato_ was, of course, Mr. Potato (R), * _woody_ was the cowboy, * _sarge_ was the sergeant of the Green Plastic Army Men, * _etch_ was the toy blackboard (Etch-a-Sketch (R)), * _lenny_ was the binoculars. * _sid_ was the boy next door who destroyed toys. 6.4. What about "sid"? ---------------------- _sid_ or _unstable_ is the place where most of the packages are initially uploaded. It will never be released directly, because packages which are to be released will first have to be included in _testing_, in order to be released in _stable_ later on. sid contains packages for both released and unreleased architectures. The name "sid" also comes from the "Toy Story" animated motion picture: Sid was the boy next door who destroyed toys :-) [1] [1] When the present-day sid did not exist, the FTP site organization had one major flaw: there was an assumption that when an architecture is created in the current unstable, it will be released when that distribution becomes the new stable. For many architectures that isn't the case, with the result that those directories had to be moved at release time. This was impractical because the move would chew up lots of bandwidth. The archive administrators worked around this problem for several years by placing binaries for unreleased architectures in a special directory called "sid". For those architectures not yet released, the first time they were released there was a link from the current stable to sid, and from then on they were created inside the unstable tree as normal. This layout was somewhat confusing to users. With the advent of package pools (see Section 6.10, `What's in the `pool' directory?'), binary packages began to be stored in a canonical location in the pool, regardless of the distribution, so releasing a distribution no longer causes large bandwidth consumption on the mirrors (there is, however, a lot of gradual bandwidth consumption throughout the development process). 6.5. What does the stable directory contain? -------------------------------------------- * stable/main/: This directory contains the packages which formally constitute the most recent release of the Debian GNU/Linux system. These packages all comply with the Debian Free Software Guidelines (http://www.debian.org/social_contract#guidelines), and are all freely usable and distributable. * stable/non-free/: This directory contains packages distribution of which is restricted in a way that requires that distributors take careful account of the specified copyright requirements. For example, some packages have licenses which prohibit commercial distribution. Others can be redistributed but are in fact shareware and not freeware. The licenses of each of these packages must be studied, and possibly negotiated, before the packages are included in any redistribution (e.g., in a CD-ROM). * stable/contrib/: This directory contains packages which are DFSG-free and _freely distributable_ themselves, but somehow depend on a package that is _not_ freely distributable and thus available only in the non-free section. 6.6. What does the testing directory contain? --------------------------------------------- Packages are installed into the `testing' directory after they have undergone some degree of testing in unstable. They must be in sync on all architectures where they have been built and mustn't have dependencies that make them uninstallable; they also have to have fewer release-critical bugs than the versions currently in testing. This way, we hope that `testing' is always close to being a release candidate. More information about the status of "testing" in general and the individual packages is available at http://www.debian.org/devel/testing 6.6.1. What about "testing"? How is it `frozen'? ------------------------------------------------ When the "testing" distribution is mature enough, the release manager starts `freezing' it. The normal propagation delays are increased to ensure that as little as possible new bugs from "unstable" enter "testing". After a while, the "testing" distribution becomes truly `frozen'. This means that all new packages that are to propagate to the "testing" are held back, unless they include release-critical bug fixes. The "testing" distribution can also remain in such a deep freeze during the so-called `test cycles', when the release is imminent. We keep a record of bugs in the "testing" distribution that can hold off a package from being released, or bugs that can hold back the whole release. For details, please see current testing release information (http://www.debian.org/releases/testing/). Once that bug count lowers to maximum acceptable values, the frozen "testing" distribution is declared "stable" and released with a version number. With each new release, the previous "stable" distribution becomes obsolete and moves to the archive. For more information please see Debian archive (http://www.debian.org/distrib/archive). 6.7. What does the unstable directory contain? ---------------------------------------------- The `unstable' directory contains a snapshot of the current development system. Users are welcome to use and test these packages, but are warned about their state of readiness. The advantage of using the unstable distribution is that you are always up-to-date with the latest in GNU/Linux software industry, but if it breaks: you get to keep both parts :-) There are also main, contrib and non-free subdirectories in `unstable', separated on the same criteria as in `stable'. 6.8. What are all those directories inside `dists/stable/main'? --------------------------------------------------------------- Within each of the major directory trees[1], there are three sets of subdirectories containing index files. There's one set of `binary-' subdirectories which contain index files for binary packages of each available computer architecture, for example `binary-i386' for packages which execute on Intel x86 PC machines or `binary-sparc' for packages which execute on Sun SPARCStations. The complete list of available architectures for each release is available at the release's web page (http://www.debian.org/releases/). For the current release, please see Section 4.1, `On what hardware architectures/systems does Debian GNU/Linux run?'. The index files in binary-* are called Packages(.gz) and they include a summary of each binary package that is included in that distribution. The actual binary packages (for _woody_ and subsequent releases) reside in the top level `pool' directory. Furthermore, there's a subdirectory called source/ which contains index files for source packages included in the distribution. The index file is called Sources(.gz). Last but not least, there's a set of subdirectories meant for the installation system index files. In the _woody_ release, these are named `disks-'; in _sarge_ and later releases, they are at `debian-installer/binary-'. [1] `dists/stable/main', `dists/stable/contrib', `dists/stable/non-free', and `dists/unstable/main/', etc. 6.9. Where is the source code? ------------------------------ Source code is included for everything in the Debian system. Moreover, the license terms of most programs in the system _require_ that source code be distributed along with the programs, or that an offer to provide the source code accompany the programs. The source code is distributed in the `pool' directory (see Section 6.10, `What's in the `pool' directory?') together with all the architecture-specific binary directories. To retrieve the source code without having to be familiar with the structure of the FTP archive, try a command like `apt-get source mypackagename'. Some packages are only distributed as source code due to the restrictions in their licenses. Notably, one such package is `pine', see Section 5.11, `Where is pine?' for more information. Source code may or may not be available for packages in the "contrib" and "non-free" directories, which are not formally part of the Debian system. 6.10. What's in the `pool' directory? ------------------------------------- Packages are kept in a large `pool', structured according to the name of the source package. To make this manageable, the pool is subdivided by section (`main', `contrib' and `non-free') and by the first letter of the source package name. These directories contain several files: the binary packages for each architecture, and the source packages from which the binary packages were generated. You can find out where each package is placed by executing a command like `apt-cache showsrc mypackagename' and looking at the `Directory:' line. For example, the `apache' packages are stored in `pool/main/a/apache/'. Additionally, since there are so many `lib*' packages, these are treated specially: for instance, libpaper packages are stored in `pool/main/libp/libpaper/'. [1] [1] Historically, packages were kept in the subdirectory of `dists' corresponding to which distribution contained them. This turned out to cause various problems, such as large bandwidth consumption on mirrors when major changes were made. This was fixed with the introduction of the package pool. The `dists' directories are still used for the index files used by programs like `apt'. You may also still see paths containing `dists/potato' or `dists/woody' in the Filename header field of some older packages. 6.11. What is "incoming"? ------------------------- After a developer uploads a package, it stays for a short while in the "incoming" directory before it is checked that it's genuine and allowed into the archive. Usually nobody should install things from this place. However, in some rare cases of emergency, the incoming directory is available at http://incoming.debian.org/. You can manually fetch packages, check the GPG signature and MD5sums in the .changes and .dsc files, and then install them. 6.12. How do I set up my own apt-able repository? ------------------------------------------------- If you have built some private Debian packages which you'd like to install using the standard Debian package management tools, you can set up your own apt-able package archive. This is also useful if you'd like to share your Debian packages while these are not distributed by the Debian project. Instructions on how to do this are given in the Debian Repository HOWTO (http://www.debian.org/doc/manuals/repository-howto/repository-howto). ------------------------------------------------------------------------------- 7. Basics of the Debian package management system ------------------------------------------------- 7.1. What is a Debian package? ------------------------------ Packages generally contain all of the files necessary to implement a set of related commands or features. There are two types of Debian packages: * _Binary packages_, which contain executables, configuration files, man/info pages, copyright information, and other documentation. These packages are distributed in a Debian-specific archive format (see Section 7.2, `What is the format of a Debian binary package?'); they are usually distinguished by having a '.deb' file extension. Binary packages can be unpacked using the Debian utility `dpkg'; details are given in its manual page. * _Source packages_, which consist of a `.dsc' file describing the source package (including the names of the following files), a `.orig.tar.gz' file that contains the original unmodified source in gzip-compressed tar format and usually a `.diff.gz' file that contains the Debian-specific changes to the original source. The utility `dpkg-source' packs and unpacks Debian source archives; details are provided in its manual page. Installation of software by the package system uses "dependencies" which are carefully designed by the package maintainers. These dependencies are documented in the `control' file associated with each package. For example, the package containing the GNU C compiler (`gcc') "depends" on the package `binutils' which includes the linker and assembler. If a user attempts to install `gcc' without having first installed `binutils', the package management system (dpkg) will send an error message that it also needs `binutils', and stop installing `gcc'. (However, this facility can be overridden by the insistent user, see dpkg(8).) See more in Section 7.9, `What is meant by saying that a package _Depends_, _Recommends_, _Suggests_, _Conflicts_, _Replaces_ or _Provides_ another package?' below. Debian's packaging tools can be used to: * manipulate and manage packages or parts of packages, * aid the user in the break-up of packages that must be transmitted through a limited-size medium such as floppy disks, * aid developers in the construction of package archives, and * aid users in the installation of packages which reside on a remote FTP site. 7.2. What is the format of a Debian binary package? --------------------------------------------------- A Debian "package", or a Debian archive file, contains the executable files, libraries, and documentation associated with a particular suite of program or set of related programs. Normally, a Debian archive file has a filename that ends in `.deb'. The internals of this Debian binary packages format are described in the deb(5) manual page. This internal format is subject to change (between major releases of Debian GNU/Linux), therefore please always use dpkg-deb(1) for manipulating `.deb' files. 7.3. Why are Debian package file names so long? ----------------------------------------------- The Debian binary package file names conform to the following convention: _-_.deb Note that `foo' is supposed to be the package name. As a check, one can learn the package name associated with a particular Debian archive file (.deb file) in one of these ways: * inspect the "Packages" file in the directory where it was stored at a Debian FTP archive site. This file contains a stanza describing each package; the first field in each stanza is the formal package name. * use the command `dpkg --info foo_VVV-RRR_AAA.deb' (where VVV, RRR and AAA are the version, revision and architecture of the package in question, respectively). This displays, among other things, the package name corresponding to the archive file being unpacked. The `VVV' component is the version number specified by the upstream developer. There are no standards in place here, so the version number may have formats as different as "19990513" and "1.3.8pre1". The `RRR' component is the Debian revision number, and is specified by the Debian developer (or an individual user if he chooses to build the package himself). This number corresponds to the revision level of the Debian package, thus, a new revision level usually signifies changes in the Debian Makefile (`debian/rules'), the Debian control file (`debian/control'), the installation or removal scripts (`debian/p*'), or in the configuration files used with the package. The `AAA' component identifies the processor for which the package was built. This is commonly `i386', which refers to chips compatible to Intel's 386 or later versions. For other possibilities review Debian's FTP directory structure at Section 6.1, `What are all those directories at the Debian FTP archives?'. For details, see the description of "Debian architecture" in the manual page dpkg-architecture(1). 7.4. What is a Debian control file? ----------------------------------- Specifics regarding the contents of a Debian control file are provided in the Debian Policy Manual, section 5, see Section 12.1, `What other documentation exists on and for a Debian system?'. Briefly, a sample control file is shown below for the Debian package hello: Package: hello Priority: optional Section: devel Installed-Size: 45 Maintainer: Adam Heath Architecture: i386 Version: 1.3-16 Depends: libc6 (>= 2.1) Description: The classic greeting, and a good example The GNU hello program produces a familiar, friendly greeting. It allows nonprogrammers to use a classic computer science tool which would otherwise be unavailable to them. . Seriously, though: this is an example of how to do a Debian package. It is the Debian version of the GNU Project's `hello world' program (which is itself an example for the GNU Project). The Package field gives the package name. This is the name by which the package can be manipulated by the package tools, and usually similar to but not necessarily the same as the first component string in the Debian archive file name. The Version field gives both the upstream developer's version number and (in the last component) the revision level of the Debian package of this program as explained in Section 7.3, `Why are Debian package file names so long?'. The Architecture field specifies the chip for which this particular binary was compiled. The Depends field gives a list of packages that have to be installed in order to install this package successfully. The Installed-Size indicates how much disk space the installed package will consume. This is intended to be used by installation front-ends in order to show whether there is enough disk space available to install the program. The Section line gives the "section" where this Debian package is stored at the Debian FTP sites. This is the name of a subdirectory (within one of the main directories, see Section 6.1, `What are all those directories at the Debian FTP archives?') where the package is stored. The Priority indicates how important is this package for installation, so that semi-intelligent software like dselect or console-apt can sort the package into a category of e.g. packages optionally installed. See Section 7.7, `What is an _Essential_ _Required_, _Important_, _Standard_, _Optional_, or _Extra_ package?'. The Maintainer field gives the e-mail address of the person who is currently responsible for maintaining this package. The Description field gives a brief summary of the package's features. For more information about all possible fields a package can have, please see the Debian Policy Manual, section 5., "Control files and their fields". 7.5. What is a Debian conffile? ------------------------------- Conffiles is a list of configuration files (usually placed in `/etc') that the package management system will not overwrite when the package is upgraded. This ensures that local values for the contents of these files will be preserved, and is a critical feature enabling the in-place upgrade of packages on a running system. To determine exactly which files are preserved during an upgrade, run: dpkg --status package And look under "Conffiles:". 7.6. What is a Debian preinst, postinst, prerm, and postrm script? ------------------------------------------------------------------ These files are executable scripts which are automatically run before or after a package is installed. Along with a file named `control', all of these files are part of the "control" section of a Debian archive file. The individual files are: preinst This script executes before that package will be unpacked from its Debian archive (".deb") file. Many 'preinst' scripts stop services for packages which are being upgraded until their installation or upgrade is completed (following the successful execution of the 'postinst' script). postinst This script typically completes any required configuration of the package `foo' once `foo' has been unpacked from its Debian archive (".deb") file. Often, 'postinst' scripts ask the user for input, and/or warn the user that if he accepts default values, he should remember to go back and re-configure that package as the situation warrants. Many 'postinst' scripts then execute any commands necessary to start or restart a service once a new package has been installed or upgraded. prerm This script typically stops any daemons which are associated with a package. It is executed before the removal of files associated with the package. postrm This script typically modifies links or other files associated with `foo', and/or removes files created by the package. (Also see Section 7.8, `What is a Virtual Package?'.) Currently all of the control files can be found in directory `/var/lib/dpkg/info'. The files relevant to package `foo' begin with the name "foo" and have file extensions of "preinst", "postinst", etc., as appropriate. The file `foo.list' in that directory lists all of the files that were installed with the package `foo'. (Note that the location of these files is a dpkg internal; you should not rely on it.) 7.7. What is an _Essential_ _Required_, _Important_, _Standard_, _Optional_, or _Extra_ package? ---------------------------------------------------------------------------- Each Debian package is assigned a _priority_ by the distribution maintainers, as an aid to the package management system. The priorities are: * _Required_: packages that are necessary for the proper functioning of the system. This includes all tools that are necessary to repair system defects. You must not remove these packages or your system may become totally broken and you may probably not even be able to use dpkg to put things back. Systems with only the Required packages are probably unusable, but they do have enough functionality to allow the sysadmin to boot and install more software. * _Important_ packages should be found on any Unix-like system. Other packages which the system will not run well or be usable without will be here. This does _NOT_ include Emacs or X11 or TeX or any other large applications. These packages only constitute the bare infrastructure. * _Standard_ packages are standard on any Linux system, including a reasonably small but not too limited character-mode system. Tools are included to be able to browse the web (using w3m), send e-mail (with mutt) and download files from FTP servers. This is what will install by default if users do not select anything else. It does not include many large applications, but it does include the Python interpreter and some server software like OpenSSH (for remote administration), Exim (for mail delivery, although it can be configured for local delivery only), an identd server (pidentd) and the RPC portmapper (`portmap'). It also includes some common generic documentation that most users will find helpful. * _Optional_ packages include all those that you might reasonably want to install if you did not know what it was, or do not have specialized requirements. This includes X11, a full TeX distribution, and lots of applications. * _Extra_: packages that either conflict with others with higher priorities, are only likely to be useful if you already know what they are, or have specialized requirements that make them unsuitable for "Optional". If you do a default Debian installation all the packages of priority _Standard_ or higher will be installed in your system. If you select pre-defined tasks you will get lower priority packages too. Additionally, some packages are marked as _Essential_ since they are absolutely necessary for the proper functioning of the system. The package management tools will refuse to remove these. 7.8. What is a Virtual Package? ------------------------------- A virtual package is a generic name that applies to any one of a group of packages, all of which provide similar basic functionality. For example, both the `tin' and `trn' programs are news readers, and should therefore satisfy any dependency of a program that required a news reader on a system, in order to work or to be useful. They are therefore both said to provide the "virtual package" called `news-reader'. Similarly, `smail' and `sendmail' both provide the functionality of a mail transport agent. They are therefore said to provide the virtual package, "mail transport agent". If either one is installed, then any program depending on the installation of a `mail-transport-agent' will be satisfied by the existence of this virtual package. Debian provides a mechanism so that, if more than one package which provide the same virtual package is installed on a system, then system administrators can set one as the preferred package. The relevant command is `update-alternatives', and is described further in Section 11.10, `Some users like mawk, others like gawk; some like vim, others like elvis; some like trn, others like tin; how does Debian support diversity?'. 7.9. What is meant by saying that a package _Depends_, _Recommends_, _Suggests_, _Conflicts_, _Replaces_ or _Provides_ another package? ---------------------------------------------------------------------------- The Debian package system has a range of package "dependencies" which are designed to indicate (in a single flag) the level at which Program A can operate independently of the existence of Program B on a given system: * Package A _depends_ on Package B if B absolutely must be installed in order to run A. In some cases, A depends not only on B, but on a version of B. In this case, the version dependency is usually a lower limit, in the sense that A depends on any version of B more recent than some specified version. * Package A _recommends_ Package B, if the package maintainer judges that most users would not want A without also having the functionality provided by B. * Package A _suggests_ Package B if B contains files that are related to (and usually enhance) the functionality of A. * Package A _conflicts_ with Package B when A will not operate if B is installed on the system. Most often, conflicts are cases where A contains files which are an improvement over those in B. "Conflicts" are often combined with "replaces". * Package A _replaces_ Package B when files installed by B are removed and (in some cases) over-written by files in A. * Package A _provides_ Package B when all of the files and functionality of B are incorporated into A. This mechanism provides a way for users with constrained disk space to get only that part of package A which they really need. More detailed information on the use of each these terms can be found in the Policy manual. 7.10. What is meant by Pre-Depends? ----------------------------------- "Pre-Depends" is a special dependency. In the case of most packages, `dpkg' will unpack its archive file (i.e., its `.deb' file) independently of whether or not the files on which it depends exist on the system. Simplistically, unpacking means that `dpkg' will extract the files from the archive file that were meant to be installed on your file system, and put them in place. If those packages _depend_ on the existence of some other packages on your system, `dpkg' will refuse to complete the installation (by executing its "configure" action) until the other packages are installed. However, for some packages, `dpkg' will refuse even to unpack them until certain dependencies are resolved. Such packages are said to "Pre-depend" on the presence of some other packages. The Debian project provided this mechanism to support the safe upgrading of systems from `a.out' format to `ELF' format, where the _order_ in which packages were unpacked was critical. There are other large upgrade situations where this method is useful, e.g. the packages with the required priority and their LibC dependency. As before, more detailed information about this can be found in the Policy manual. 7.11. What is meant by _unknown_, _install_, _remove_ _purge_ and _hold_ in the package status? ---------------------------------------------------------------------------- These "want" flags tell what the user wanted to do with a package (as indicated either by the user's actions in the "Select" section of `dselect', or by the user's direct invocations of `dpkg'). Their meanings are: * unknown - the user has never indicated whether he wants the package * install - the user wants the package installed or upgraded * remove - the user wants the package removed, but does not want to remove any existing configuration files. * purge - the user wants the package to be removed completely, including its configuration files. * hold - the user wants this package not to be processed, i.e., he wants to keep the current version with the current status whatever that is. 7.12. How do I put a package on hold? ------------------------------------- There are three ways of holding back packages, with dpkg, aptitude or with dselect. With dpkg, you just have to export the list of package selections, with: dpkg --get-selections \* > selections.txt Then edit the resulting file `selections.txt', change the line containing the package you wish to hold, e.g. `libc6', from this: libc6 install to this: libc6 hold Save the file, and reload it into dpkg database with: dpkg --set-selections < selections.txt With aptitude, you can hold a package using aptitude hold package_name and remove the hold with aptitude unhold package_name With dselect, you just have to enter the [S]elect screen, find the package you wish to hold in its present state, and press the `=' key (or `H'). The changes will go live immediately after you exit the [S]elect screen. 7.13. How do I install a source package? ---------------------------------------- Debian source packages can't actually be "installed", they are just unpacked in whatever directory you want to build the binary packages they produce. Source packages are distributed on most of the same mirrors where you can obtain the binary packages. If you set up your APT's sources.list(5) to include the appropriate "deb-src" lines, you'll be able to easily download any source packages by running apt-get source foo To help you in actually building the source package, Debian source package provide the so-called build-dependencies mechanism. This means that the source package maintainer keeps a list of other packages that are required to build their package. To see how this is useful, run apt-get build-dep foo before building the source. 7.14. How do I build binary packages from a source package? ----------------------------------------------------------- You will need all of foo_*.dsc, foo_*.tar.gz and foo_*.diff.gz to compile the source (note: there is no .diff.gz for some packages that are native to Debian). Once you have them (Section 7.13, `How do I install a source package?'), if you have the `dpkg-dev' package installed, the following command: dpkg-source -x foo_version-revision.dsc will extract the package into a directory called `foo-version'. If you want just to compile the package, you may cd into `foo-version' directory and issue the command dpkg-buildpackage -rfakeroot -b to build the package (note that this also requires the `fakeroot' package), and then dpkg -i ../foo_version-revision_arch.deb to install the newly-built package(s). 7.15. How do I create Debian packages myself? --------------------------------------------- For more detailed description on this, read the New Maintainers' Guide, available in the `maint-guide' package, or at http://www.debian.org/doc/devel-manuals#maint-guide. ------------------------------------------------------------------------------- 8. The Debian package management tools -------------------------------------- 8.1. What programs does Debian provide for managing its packages? ----------------------------------------------------------------- There are multiple tools that are used to manage Debian packages, from graphic or text-based interfaces to the low level tools used to install packages. All the available tools rely on the lower level tools to properly work and are presented here in decreasing complexity level. It is important to understand that the higher level package management tools such as `aptitude' or `dselect' rely on `apt' which, itself, relies on `dpkg' to manage the packages in the system. See the APT HOWTO (http://www.debian.org/doc/manuals/apt-howto/) for more information about the Debian package management utilities. This document is available in various languages and formats, see the APT HOWTO entry on the DDP Users' Manuals overview (http://www.debian.org/doc/user-manuals#apt-howto). 8.1.1. dpkg ----------- This is the main package management program. `dpkg' can be invoked with many options. Some common uses are: * Find out all the options: `dpkg --help'. * Print out the control file (and other information) for a specified package: `dpkg --info foo_VVV-RRR.deb' * Install a package (including unpacking and configuring) onto the file system of the hard disk: `dpkg --install foo_VVV-RRR.deb'. * Unpack (but do not configure) a Debian archive into the file system of the hard disk: `dpkg --unpack foo_VVV-RRR.deb'. Note that this operation does _not_ necessarily leave the package in a usable state; some files may need further customization to run properly. This command removes any already-installed version of the program and runs the preinst (see Section 7.6, `What is a Debian preinst, postinst, prerm, and postrm script?') script associated with the package. * Configure a package that already has been unpacked: `dpkg --configure foo'. Among other things, this action runs the postinst (see Section 7.6, `What is a Debian preinst, postinst, prerm, and postrm script?') script associated with the package. It also updates the files listed in the `conffiles' for this package. Notice that the 'configure' operation takes as its argument a package name (e.g., foo), _not_ the name of a Debian archive file (e.g., foo_VVV-RRR.deb). * Extract a single file named "blurf" (or a group of files named "blurf*" from a Debian archive: `dpkg --fsys-tarfile foo_VVV-RRR.deb | tar -xf - blurf*' * Remove a package (but not its configuration files): `dpkg --remove foo'. * Remove a package (including its configuration files): `dpkg --purge foo'. * List the installation status of packages containing the string (or regular expression) "foo*": `dpkg --list 'foo*''. 8.1.2. APT ---------- APT is the _Advanced Package Tool_ and provides the `apt-get' program. `apt-get' provides a simple way to retrieve and install packages from multiple sources using the command line. Unlike `dpkg', `apt-get' does not understand .deb files, it works with the packages proper name and can only install .deb archives from a source specified in `/etc/apt/sources.list'. `apt-get' will call `dpkg' directly after downloading the .deb archives[1] from the configured sources. Some common ways to use `apt-get' are: * To update the list of package known by your system, you can run: apt-get update (you should execute this regularly to update your package lists) * To upgrade all the packages on your system, run: apt-get upgrade * To install the package and all its dependencies, run: apt-get install foo * To remove the foo package from your system, run: apt-get remove foo * To remove the foo package and its configuration files from your system, run: apt-get --purge remove foo * To upgrade all the packages on your system to a new Debian GNU/Linux release, run: apt-get dist-upgrade Note that you must be logged in as root to perform any commands that modify the system packages. The apt tool suite also includes the `apt-cache' tool to query the package lists. You can use it to find packages providing specific functionality through simple text or regular expression queries and through queries of dependencies in the package management system. Some common ways to use `apt-cache' are: * To find packages whose description contain : apt-cache search * To print the detailed information of a package: apt-cache show * To print the packages a given package depends on: apt-cache depends * To print detailed information of the versions available for a package and the packages that reverse-depends on it: apt-cache showpkg For more information, install the `apt' package and read apt-get(8), sources.list(5) and install the `apt-doc' package and read `/usr/share/doc/apt-doc/guide.html/index.html'. [1] Notice that there are ports that make this tool available with other package management systems, like Red Hat package manager, also known as `rpm' 8.1.3. aptitude --------------- `aptitude' is a package manager for Debian GNU/Linux systems that provides a frontend to the apt package management infrastructure. `aptitude' is a text-based interface using the curses library, it can be used to perform management tasks in a fast and easy way. `aptitude' provides the functionality of `dselect' and `apt-get', as well as many additional features not found in either program: * `aptitude' offers access to all versions of a package. * `aptitude' logs all its actions in `/var/log/aptitude'. * `aptitude' makes it easy to keep track of obsolete software by listing it under "Obsolete and Locally Created Packages". * `aptitude' includes a fairly powerful system for searching particular packages and limiting the package display. Users familiar with `mutt' will pick up quickly, as `mutt' was the inspiration for the expression syntax. * `aptitude' tracks which packages have been installed due to dependencies and removes them automatically when the packages that needed them are removed from the system. * `aptitude' can automatically install _Recommended:_ packages[1]. * `aptitude' can be used to install the predefined tasks available. For more information see Section 8.1.4, `tasksel'. * `aptitude' in full screen mode has `su' functionality embedded and can be run by a normal user. It will call `su' (and ask for the root password, if any) when you really need administrative privileges You can use `aptitude' through a visual interface (simply run `aptitude') or directly from the command line. The command line syntax used is very similar to the one used in `apt-get'. For example, to install the package, you can run `aptitude install '. Note that `aptitude' is the preferred program for package management from console both for package installations and package or system upgrades. For more informations, read the manual page aptitude(8) and install the `aptitude-doc-en' package. [1] Although this can also lead to systems with more packages installed than they actually need to work. 8.1.4. tasksel -------------- When you want to perform a specific task it might be difficult to find the appropiate suite of packages that fill your need. The Debian developers have defined `tasks', a task is a collection of several individual Debian packages all related to a specific activity. Tasks can be installed through the `tasksel' program or through `aptitude'. The Debian installer will typically install automaticaly, the task associated with a standard system and a desktop environment. The specific desktop environment installed will depend on the CD/DVD media used, most commonly it will be the GNOME desktop (`gnome-desktop' task). Also, depending on your selections throughout the installation process, tasks might be automatically installed in your system. For example, if you selected a language, the task associated with it will be installed automatically too and if you are running in a laptop system the installer recognises the `laptop' task will be installed too. 8.1.5. dselect -------------- This program is a menu-driven interface to the Debian package management system. This was the main package management interface for for first-time installations, but users are encouraged to use `aptitude' instead. Some users might feel more comfortable using `aptitude' and it is also recommended over `dselect' for large-scale upgrades. For more information on `aptitude' please see Section 8.1.3, `aptitude'. `dselect' can: * guide the user as he/she chooses among packages to install or remove, ensuring that no packages are installed that conflict with one another, and that all packages required to make each package work properly are installed; * warn the user about inconsistencies or incompatibilities in their selections; * determine the order in which the packages must be installed; * automatically perform the installation or removal; and * guide the user through whatever configuration process are required for each package. `dselect' begins by presenting the user with a menu of 7 items, each of which is a specific action. The user can select one of the actions by using the arrow keys to move the highlighter bar, then pressing the __ key to select the highlighted action. What the user sees next depends on the action he selected. If he selects any option but `Access' or `Select', then `dselect' will simply proceed to execute the specified action: e.g., if the user selected the action `Remove', then dselect would proceed to remove all of the files selected for removal when the user last chose the `Select' action. Both the `Access' menu item and the `Select' menu item lead to additional menus. In both cases, the menus are presented as split screens; the top screen gives a scrollable list of choices, while the bottom screen gives a brief explanation ("info") for each choice. Extensive on-line help is available, use the '?' key to get to a help screen at any time. The order in which the actions are presented in the first `dselect' menu represents the order in which a user would norm