The Debian GNU/Linux system is maintained and distributed as a collection of packages. Since there are so many of them (over 2600) they are split into sections and priorities to simplify handling of them.
The effort of the Debian project is to build a free operating system, but not every package we want to make accessible is free in our sense (see Debian Free Software Guidelines, below), or may be imported/exported without restrictions. Thus, the archive is split into the sections main, non-us, non-free, and contrib.
The main section forms the Debian GNU/Linux distribution.
Packages in the other sections are not considered as part of the Debian distribution, though we support their use, and we provide infrastructure for them (such as our bug-tracking system and mailing lists). This Debian Policy Manual applies to these packages as well.
The aims of this policy are:
The Debian Free Software Guidelines (DFSG) is our definition of `free' software.
Every package in "main" must comply with the DFSG (Debian Free Software Guidelines).
In addition, the packages in "main"
Every package in "contrib" must comply with the DFSG.
Examples of packages which would be included in "contrib" are
`Non-free' contains packages which are not compliant with the DFSG or which are encumbered by patents or other legal issues that make their distribution problematic.
All packages in `non-free' must be electronically distributable across international borders.
Some programs with cryptographic program code must be stored on the "non-us" server because of export restrictions of the U.S.
This applies only to packages which contain cryptographic code. A package containing a program with an interface to a cryptographic program or a program that's dynamically linked against a cryptographic library can be distributed if it is capable of running without the cryptography library or program.
Every package must be accompanied by a verbatim copy of its copyright and distribution license in the file /usr/share/doc/<package-name>/copyright (see Copyright information, Section 6.6 for details).
We reserve the right to restrict files from being included anywhere in our archives if
Programs whose authors encourage the user to make donations are fine for the main distribution, provided that the authors do not claim that not donating is immoral, unethical, illegal or something similar; otherwise they must go in contrib (or non-free, if even distribution is restricted by such statements).
Packages whose copyright permission notices (or patent problems) do not allow redistribution even of only binaries, and where no special permission has been obtained, cannot be placed on the Debian FTP site and its mirrors at all.
Note, that under international copyright law (this applies in the United States, too) no distribution or modification of a work is allowed without an explicit notice saying so. Therefore a program without a copyright notice is copyrighted and you may not do anything to it without risking being sued! Likewise if a program has a copyright notice but no statement saying what is permitted then nothing is permitted.
Many authors are unaware of the problems that restrictive copyrights (or lack of copyright notices) can cause for the users of their supposedly-free software. It is often worthwhile contacting such authors diplomatically to ask them to modify their license terms. However, this is a politically difficult thing to do and you should ask for advice on debian-devel first.
When in doubt, send mail to debian-devel@lists.debian.org.
Be prepared to provide us with the copyright statement. Software covered by
the GPL, public domain software and BSD-like copyrights are safe; be wary of
the phrases `commercial use prohibited' and `distribution restricted'.
The packages in all the sections (main, contrib, non-US/main, non-free, non-US/contrib, and non-US/non-free) are grouped further into subsections to simplify handling.
The section for each package is specified in the package's control record. However, the maintainer of the Debian archive may override this selection to assure the consistency of the Debian distribution.
Please check the current Debian distribution to see which sections are available.
Each package is given a certain priority value, which is included in the package's control record. This information is used in the Debian package management tool to separate high-priority packages from less-important packages.
The following priority levels are supported by the Debian package
management system, dpkg.
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.
foo', it must be in important. This is an important
criterion because we are trying to produce, amongst other things, a free Unix.
Other packages without which the system will not run well or be usable must
also be here. This does not include Emacs, the X Window System, TeX
or any other large applications. The important packages are just
a bare minimum of commonly-expected and necessary tools.
Packages may not depend on packages with lower priority values (excluding build-time dependencies). If this does happen, one of the priority values will have to be adapted.
The Debian GNU/Linux distribution is based on the Debian package management
system, called dpkg. Thus, all packages in the Debian
distribution have to be provided in the .deb file format.
Every package must have a name that's unique within the Debian archive.
Package names may only consist of lower case letters, digits (0-9), plus (+) or minus (-) signs, and periods (.).
The package name is part of the file name of the .deb file and is included in the control field information.
Every package must have exactly one maintainer at a time. This person is responsible that the license of the package's software complies with the policy of the distribution this package is included in.
The maintainer must be specified in the Maintainer control field with the correct name and a working email address for the Debian maintainer of the package. If one person maintains several packages he/she should try to avoid having different forms of their name and email address in different Maintainer fields.
If the maintainer of a package quits from the Debian project the Debian QA
Group debian-qa@lists.debian.org
takes over the maintainership of the package until someone else volunteers for
that task. These packages are called orphaned packages.
Every Debian package must have an extended description stored in the appropriate field of the control record.
The description must be written so that it tells the user what they need to know to decide whether to install the package. This description should not just be copied from the blurb for the program. Instructions for configuring or using the package must not be included -- that is what installation scripts, manual pages, Info files, etc. are for. Copyright statements and other administrivia must not be included -- that is what the copyright file is for.
Every package has to specify the dependency information about other packages, that are required for the first to work correctly.
For example, for any shared libraries required by dynamically-linked executable binary in a package a dependency entry has to be provided.
It is not necessary for other packages to declare any dependencies they have on other packages which are marked Essential (see below).
Sometimes, a package requires another package to be installed and configured before it can be installed. In this case, you'll have to specify a Pre-Depends entry for the package.
You must not specify a Pre-Depends entry for a package before this has been discussed on the debian-devel mailing list and a consensus about doing that has been reached.
Sometimes, there are several packages doing more-or-less the same job. In this case, it's useful to define a virtual package who's name describes the function the packages have. (The virtual packages just exist logically, not physically--that's why they are called virtual.) The packages with this particular function will then provide the virtual package. Thus, any other package requiring that function can simply depend on the virtual package without having to specify all possible packages individually.
All packages must use virtual package names where appropriate, and arrange to create new ones if necessary. They must not use virtual package names (except privately, amongst a cooperating group of packages) unless they have been agreed upon and appear in the list of virtual package names.
The latest version of the authoritative list of virtual package names can be
found on ftp.debian.org in /debian/doc/package-developer/virtual-package-names-list.text
or your local mirror. In addition, it is included in the
debian-policy package. The procedure for updating the list is
described at the top of the file.
The packages included in the base section have a special function. They form a minimum subset of the Debian GNU/Linux system that is installed before everything else on a new system. Thus, only very few packages are allowed to go into the base section to keep the required disk usage very small.
Most of these packages should have the priority value required or at least important, and many of them will be tagged essential (see below).
You must not place any packages into the base section before this has been discussed on the debian-devel mailing list and a consensus about doing that has been reached.
Some packages are tagged essential. (They have Essential: yes in their package control record.) This flag is used for packages that are essential for a system.
Since these packages can ortant packages.
The following priority levels are supported by the Debian package
management system, dpkg.
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.
foo', it must be in important. This is an important
criterion because we are trying to produce, amongst other things, a free Unix.
Other packages without which the system will not run well or be usable must
also be here. This does not include Emacs, the X Window System, TeX
or any other large applications. The important packages are just
a bare minimum of commonly-expected and necessary tools.
Packages may not depend on packages with lower priority values (excluding build-time dependencies). If this does happen, one of the priority values will have to be adapted.
The Debian GNU/Linux distribution is based on the Debian package management
system, called dpkg. Thus, all packages in the Debian
distribution have to be provided in the .deb file format.
Every package must have a name that's unique within the Debian archive.
Package names may only consist of lower case letters, digits (0-9), plus (+) or minus (-) signs, and periods (.).
The package name is part of the file name of the .deb file and is included in the control field information.
Every package must have exactly one maintainer at a time. This person is responsible that the license of the package's software complies with the policy of the distribution this package is included in.
The maintainer must be specified in the Maintainer control field with the correct name and a working email address for the Debian maintainer of the package. If one person maintains several packages he/she should try to avoid having different forms of their name and email address in different Maintainer fields.
If the maintainer of a package quits from the Debian project the Debian QA
Group debian-qa@lists.debian.org
takes over the maintainership of the package until someone else volunteers for
that task. These packages are called orphaned packages.
Every Debian package must have an extended description stored in the appropriate field of the control record.
The description must be written so that it tells the user what they need to know to decide whether to install the package. This description should not just be copied from the blurb for the program. Instructions for configuring or using the package must not be included -- that is what installation scripts, manual pages, Info files, etc. are for. Copyright statements and other administrivia must not be included -- that is what the copyright file is for.
Every package has to specify the dependency information about other packages, that are required for the first to work correctly.
For example, for any shared libraries required by dynamically-linked executable binary in a package a dependency entry has to be provided.
It is not necessary for other packages to declare any dependencies they have on other packages which are marked Essential (see below).
Sometimes, a package requires another package to be installed and configured before it can be installed. In this case, you'll have to specify a Pre-Depends entry for the package.
You must not specify a Pre-Depends entry for a package before this has been discussed on the debian-devel mailing list and a consensus about doing that has been reached.
Sometimes, there are several packages doing more-or-less the same job. In this case, it's useful to define a virtual package who's name describes the function the packages have. (The virtual packages just exist logically, not physically--that's why they are called virtual.) The packages with this particular function will then provide the virtual package. Thus, any other package requiring that function can simply depend on the virtual package without having to specify all possible packages individually.
All packages must use virtual package names where appropriate, and arrange to create new ones if necessary. They must not use virtual package names (except privately, amongst a cooperating group of packages) unless they have been agreed upon and appear in the list of virtual package names.
The latest version of the authoritative list of virtual package names can be
found on ftp.debian.org in /debian/doc/package-developer/virtual-package-names-list.text
or your local mirror. In addition, it is included in the
debian-policy package. The procedure for updating the list is
described at the top of the file.
The packages included in the base section have a special function. They form a minimum subset of the Debian GNU/Linux system that is installed before everything else on a new system. Thus, only very few packages are allowed to go into the base section to keep the required disk usage very small.
Most of these packages should have the priority value required or at least important, and many of them will be tagged essential (see below).
You must not place any packages into the base section before this has been discussed on the debian-devel mailing list and a consensus about doing that has been reached.
Some packages are tagged essential. (They have Essential: yes in their package control record.) This flag is used for packages that are essential for a system.
Since these packages can ortant packages.
The following priority levels are supported by the Debian package
management system, dpkg.
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.
foo', it must be in important. This is an important
criterion because we are trying to produce, amongst other things, a free Unix.
Other packages without which the system will not run well or be usable must
also be here. This does not include Emacs, the X Window System, TeX
or any other large applications. The important packages are just
a bare minimum of commonly-expected and necessary tools.
Packages may not depend on packages with lower priority values (excluding build-time dependencies). If this does happen, one of the priority values will have to be adapted.
The Debian GNU/Linux distribution is based on the Debian package management
system, called dpkg. Thus, all packages in the Debian
distribution have to be provided in the .deb file format.
Every package must have a name that's unique within the Debian archive.
Package names may only consist of lower case letters, digits (0-9), plus (+) or minus (-) signs, and periods (.).
The package name is part of the file name of the .deb file and is included in the control field information.
Every package must have exactly one maintainer at a time. This person is responsible that the license of the package's software complies with the policy of the distribution this package is included in.
The maintainer must be specified in the Maintainer