Debian

Debian is the name of both a widely used, completely non-commercial, free GNU/Linux distribution and the group of volunteers from around the world that maintain it. Debian uses the Linux kernel (the core of an operating system), but most of the basic OS tools come from the GNU project; hence the name GNU/Linux. Debian is especially well-known for its package management system, called apt, which allows relatively painless upgrades from really old versions of Debian, nearly effortless installs of new packages, and clean removal of old ones. The Debian project describes Debian as "The Universal Operating System".

The Debian project is supported by donations provided through Software in the Public Interest, a non-profit organization.

The name Debian comes from the names of its founder, Ian Murdock, and his wife, Debra. The word "Debian" is thus pronounced as the corresponding syllables of these names are in American English: /deb' ē ən/.

Several commercial Linux distributions have been based on Debian, including those from Lindows, Xandros, and Libranet.

The latest released version of Debian is called stable. In addition, there are two unreleased branches: unstable, where day-to-day development takes place, and testing, which is the staging area for the next release. Each version also has a code name dubbed after characters from the movie Toy Story; currently, (May 2003), the stable branch (version 3.0) is named "Woody", and testing (version 3.1?) is named "Sarge". Unstable is always named "sid".

Work is currently under way to port Debian to other free kernels besides Linux, including Hurd and BSD. For now, however, it is still quite accurate to describe Debian as a "Linux distribution", without further qualifications.

Table of contents 1 Project Organization 2 Developer Recruitment, Motivation, and Resignation 3 Debian package life cycle 4 Distributions based on Debian 5 External links

Project Organization

The Debian Project is a volunteer organization with three foundational documents:

• The Debian Social Contract (http://www.debian.org/social_contract) which defines set of basic principles by which the members conduct themselves;
• The Debian Free Software Guidelines (http://www.debian.org/social_contract#guidelines), which clarify what is meant by the term "free software", prominently featured in the Social Contract;
• The Debian Constitution (http://www.debian.org/devel/constitution), which describes the organizational structure for formal decision-making within the Project, and enumerates the powers and responsibilities of the Debian Project Leader, the Debian Project Secretary, and the Debian Developers generally.

The Debian Developers elect a Project Leader from within their ranks once per year. The Debian Project Leader has several special powers, but his power is not absolute. He can be recalled, or a decision reversed, by a vote of the developers under the General Resolution process. In practice, this is seldom done. (It has been over a year as of this writing since a vote was conducted under the General Resolution procedures, with the exception of the election ballot for Debian Project Leader, which must be held every year.)

The Debian Project Leader is empowered to delegate his authority, and several developers are entrusted with special responsibilities as delegates of the Project Leader, such the Debian System Administration team (who possess the root password to the Project's machines), and the Release Manager, who sets goals for the distribution's release, supervises the process, and makes the final decision as to when to release. Many delegates remain in their positions through multiple terms of the Project Leader; the most important positions are held by long-standing and well-trusted members of the Project, and there is little turnover in delegates even when the Project Leader changes.

A list of many important positions in the Debian Project is available at the Debian organization webpage (http://www.debian.org/intro/organization). Many, but not all, of these positions are delegated by the Project Leader.

Developer Recruitment, Motivation, and Resignation

The Debian Project has a steady influx of applicants wishing to become Developers. These applicants must undergo an elaborate vetting process which establishes their identity, motivation, understanding of the Project's goals (embodied in the Social Contract), and technical competence. More information on the "New Maintainer" process is available at the Debian New Maintainer page (http://www.debian.org/devel/join/newmaint).

Debian Developers join the Project for any number of reasons; some that have been cited in the past include:

• a desire to contribute back to the Free Software community (practically all applicants are users of Free Software);
• a desire to see some specific software task accomplished (some view the Debian user community as a valuable testing or proving ground for new software);
• a desire to make, or keep, Free Software competitive with proprietary alternatives;
• a desire to work closely with people that share some of their aptitudes, interests, and goals (there is a very strong sense of community within the Debian Project which some applicants do not experience in their paid jobs);
• a simple enjoyment of the iterative process of software development and maintenance (some developers have a nearly obsessive level of dedication to refinement and enhancement of software).

Debian Developers may resign their positions at any time by sending notice to the Project membership (or just the Debian System Administrators, if they wish to be discreet). Their accounts are deleted and their cryptographic keys removed from the Project's keyring (which enables package uploads signed by them to be accepted into the archive, see above).

Debian package life cycle

Each Debian package has a maintainer (typically, only one, but occasionally small teams of developers supervise particularly complex pieces of software). It is the maintainer's responsibility to keep pace with the releases of officially-authored versions of the software (called "upstream"), if any exists, ensure the portability of the package to the machine architectures that Debian supports, to ensure that the package is compliant with Debian technical policy, to fix defects in the package reported by its users (who may include other Debian developers), and author enhancements to the package which make it easier to use, more configurable, more secure, and so forth.

Periodically, a package maintainer makes a release of a package by uploading it to the "incoming" directory of the Debian package archive (or an "upload queue" which periodically batch-transmits packages to the incoming directory). At intervals (presently once per day), the incoming directory is scanned by an automated process which ensures that the upload is well-formed (all the requisite files are in place) and that the package bears the digital signature -- produced with OpenPGP[?]-compatible software -- of a Debian developer. All Debian developers have public keys. Packages are signed for two reasons; 1) to permit unsigned packages, which may have uploaded by hostile outsiders to the project, to be flagged and not processed further; and 2) to permit accountability in the event that a package contains a serious bug, a violation of policy, or malicious code.

If the package in incoming is found to be validly signed and well-formed, it is installed into the archive into an area called the "pool". Initially, all package uploads accepted into the archive are only available in the "unstable" suite of packages, which contains the most up-to-date version of each package. However, new code is also untried code, so packages are held in this development/QA area for several days (the exact duration depends on the "urgency" of the upload.

To pass from the development/QA area to the "testing" suite -- that is, the group of packages which are candidates for the next release of the Debian distribution -- a package must meet several criteria:

• it must have been in the QA area for the appropriate length of time;
• it must have no "release-critical" bugs filed against it (bugs so serious that they make it unsuitable for release);
• it must be compiled for all architectures slated to release;
• it must be a package for an architecture that is slated to release (in other words, packages for non-releasing architectures exist only in the development/QA suite, not the release-candidate suite)
• it must not depend on versions of any packages which do not meet the above conditions

Thus, as you might expect, a release-critical bug in a package on which many packages depend, such as a shared library, may prevent many packages from entering the testing area, because that library is considered deficient.

Periodically, the Release Manager, a delegate of the Debian Project Leader, in accordance with guidelines announced to the developers months in advance, decides to make a release. This occurs when all important software is reasonably up-to-date in the release-candidate suite for all architectures for which a release is planned, and when any other goals set by the Release Manager have been met. At that time, all packages in the release-candidate suite become part of the "released" suite.

It is possible for a package -- particularly an old, stable, and seldom-updated one -- to belong to more than one suite at the same time. The suites are simply collections of pointers into the package "pool" mentioned above.

Distributions based on Debian

• Knoppix
• Libranet
• Lindows
• LinEx
• Morphix[?]
• Progeny
• Stormix
• Xandros

External links

• Debian project homepage (http://www.debian.org)
• Debian wiki (http://wiki.debian.net)