This chapter provides fundamental information on the Debian system for non-developers. For authoritative information, see:
listed under References, Section 15.1.
If you are looking for less detailed "how-to" explanations, jump directly to Debian package management, Chapter 6 or other relevant chapters.
This chapter is based on documents taken from the "Debian FAQ", greatly reorganized to allow the ordinary Debian system administrator to get started.
The software that has been packaged for Debian is available in one of several
directory trees on each Debian mirror site
through FTP or HTTP.
The following directories can be found on each Debian mirror site under the
debian
directory:
dists/
:Packages.gz
files are still
in here.
pool/
:tools/
:doc/
:indices/
:project/
:project/experimental/
:project/orphaned/
:
Normally there are three Debian distributions in the dists
directory. They are named the stable distribution, the
testing distribution, and the unstable distribution.
Sometimes there is also a frozen distribution. Each distribution
is defined as a symlink to the actual directory with a codename in the
dists
directory.
Package entries for the stable distribution, Debian Woody (3.0r0),
are recorded into the stable
(symlink to woody/
)
directory:
stable/main/
: This directory contains the packages which formally
constitute the most recent release of the Debian system.
These packages all comply with the Debian Free Software
Guidelines (DFSG)
(also available as
/usr/share/doc/debian/social-contract.txt
installed by
debian-doc
), 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 free software. 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.
Now, in addition to the above locations, new physical packages are located
under the pool
directory (The pool
directory, Section 2.1.10).
The current status of stable distribution bugs is reported on the
Stable
Problems
web page.
Package entries for the testing distribution, Debian Sarge, are
recorded into the testing
(symlink to sarge/
)
directory after they have undergone some degree of testing in
unstable. Now, in addition to the above locations, new physical
packages are located under the pool
directory (The pool
directory, Section 2.1.10). There
are also main
, contrib
, and non-free
subdirectories in testing/
, which serve the same functions as in
stable/
.
These packages 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
unstable. This way, we hope that testing is always
close to being a release candidate. More details of the testing mechanism are
at http://ftp-master.debian.org/testing/
.
The latest status of the testing distribution is reported at these sites:
update
excuses
testing
problems
release-critical
bugs
base system
bugs
bugs in standard
and task packages
other bugs and bug-squashing party
notes
Package entries for the unstable distribution, always codenamed
"Sid", are recorded into the unstable
(symlink to
sid/
) directory after they are uploaded to the Debian archive and
stay here until they are moved to testing/
. New physical packages
are located under the pool
directory (The
pool
directory, Section 2.1.10). There are also
main
, contrib
and non-free
subdirectories in unstable/
, which serve the same functions as in
stable/
.
The unstable distribution contains a snapshot of the most 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 the Debian software project—but if it breaks, you get to keep both parts. :-)
The current status of unstable distribution bugs is reported on
the Unstable
Problems
web page.
When the testing distribution is mature enough, it becomes frozen,
meaning no new code is accepted anymore, just bugfixes, if necessary. Also, a
new testing tree is created in the dists
directory, assigned a new
codename. The frozen distribution passes through a few months of testing, with
intermittent updates and deep freezes called "test cycles". (The
recent Woody release process did not create a symbolic link
frozen/
, so frozen was not a distribution but just a
development stage of the testing distribution.)
We keep a record of bugs in the frozen distribution that can delay a package from being released or bugs that can hold back the whole release. Once that bug count lowers to maximum acceptable values, the frozen distribution becomes stable, it is released, and the previous stable distribution becomes obsolete (and moves to the archive).
Physical directory names in the dists
directory, such as
woody/
and sarge/
, are just "codenames".
When a Debian distribution is in the development stage, it has no version
number, but a codename instead. The purpose of these codenames is to make the
mirroring of the Debian distributions easier (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 woody/
, and
testing/
is a symbolic link to sarge/
. This means
that Woody is the current stable distribution and
Sarge is the current testing distribution.
unstable/
is a permanent symbolic link to sid/
, as
Sid is always the unstable distribution.
Other codenames that have already been 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, and "Potato" for release 2.2.
So far they have been characters taken from the movie Toy Story by Pixar.
pool
directory
Historically, packages were kept in the subdirectory of dists
corresponding to the distribution that contained them. This turned out to
cause various problems, such as large bandwidth consumption on mirrors when
major changes were made.
Packages are now 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/
. Since there are so many
lib* packages, these are treated specially: for instance,
libpaper
packages are stored in
pool/main/libp/libpaper/
.
The dists
directories are still used for the index files used by
programs like apt
. Also, at the time of writing, older
distributions have not been converted to use pools, so you'll see paths
containing distribution names such as potato or woody
in the "Directory" header field.
Normally, you won't have to worry about any of this, as new apt
and probably older dpkg-ftp
(see Methods
for upgrading a Debian system, Section 2.3.1) will handle it seamlessly.
If you want more information, see the RFC:
implementation of package pools
.
When the present-day Sid did not exist, the Debian archive site organization
had one major flaw: there was an assumption that when an architecture was
created in the current unstable/
, it would be released when that
distribution became the new stable. For many architectures that
wasn'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 usual. This layout was somewhat confusing to
users.
With the advent of package pools (see The pool
directory, Section 2.1.10) during the Woody distribution development,
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).
incoming/
Uploaded packages are first located at http://incoming.debian.org/
after
being checked to insure that they really come from a Debian developer (and are
put in the DELAYED
subdirectory in the case of a Non-Maintainer
Upload (NMU)). Once a day, they are moved out of incoming/
to
unstable/
.
In an emergency, you may want to install packages from incoming/
before they reach unstable/
.
While the most recent Debian distributions are kept under the
debian
directory on each Debian mirror site
,
archives for older Debian distributions such as Slink are kept on http://archive.debian.org/
or
under the debian-archive
directory on each Debian mirror site.
Older testing and unstable packages can be located at
http://snapshot.debian.net/
.
Within each of the major directory trees (dists/stable/main
,
dists/stable/contrib
, dists/stable/non-free
,
dists/unstable/main/
, etc.), the binary package entries reside in
subdirectories whose names indicate the chip architecture for which they were
compiled.
binary-all/
, for packages which are architecture-independent.
These include, for example, Perl scripts, or pure documentation.
binary-platform/
, for packages which execute on a
particular binary platform.
Please note that the actual binary packages for testing and
unstable no longer reside in these directories, but in the
top-level pool
directory. The index files (Packages
and Packages.gz
) have been kept, though, for backwards
compatibility.
For the actual binary architectures supported, see the Release Notes for each
distribution. They can be located at the Release Notes sites for stable
and
testing
.
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.
Normally the source code is distributed in the source
directories,
which are parallel to all the architecture-specific binary directories, or more
recently in the pool
directory (see The
pool
directory, Section 2.1.10). To retrieve the source code
without having to be familiar with the structure of the Debian archive, try a
command like apt-get source mypackagename.
Some packages, notably pine
, are only available in a source
package due to their licensing limitations. (Recently the
pine-tracker
package has been provided to facilitate Pine
installation.) The procedures described in Port a package to the stable
system, Section 6.4.10 and Packaging, Section 13.9 provide ways
to build a package manually.
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.
Packages generally contain all of the files necessary to implement a set of related commands or features. There are two types of Debian packages:
dpkg
; details
are given in its manual page.
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)
.) For additional details, see Package dependencies, Section 2.2.8 below.
Debian's packaging tools can be used to:
A Debian "package", or a Debian archive file, contains the executable files, libraries, and documentation associated with a particular program suite or set of related programs. Normally, a Debian archive file has a filename that ends in .deb. [1]
The internals of this Debian binary package format are described in the
deb(5)
manual page. Because this internal format is subject to
change (between major releases of Debian), always use dpkg-deb(8)
for manipulating .deb files.
Through at least the Sarge distribution, all Debian archive files have been
manipulable by the standard Unix commands ar
and tar
,
even when dpkg
commands are not available.
The Debian package filenames conform to the following convention:
foo_VersionNumber-DebianRevisionNumber.deb
where foo represents the package name. As a check, one can determine the package name associated with a particular Debian archive file (.deb file) in one of these ways:
The VVV component is the version number specified by the upstream developer. There are no standards governing version numbers, so they 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 the configuration files used with the package.
Preservation of user-configurable files is enabled through Debian's
"conffiles" mechanism. User configuration files (usually placed in
/etc/
) are specified in the conffiles
within the
Debian package system. The package management system guarantees not to
overwrite these files when the package is upgraded.
When it is possible to configure the system without modifying files that belong to various Debian packages, it is usually a good idea not to modify them even if they are "conffiles". This ensures faster and smoother upgrade operations.
To determine exactly which files are preserved during an upgrade, run:
dpkg --status package
and look under "Conffiles:".
Specifics regarding the contents of a Debian conffiles
file are
provided in the Debian Policy Manual, section 11.7 (see References, Section 15.1).
Debian maintenance scripts 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:
Currently all of the control files can be found in the 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, and may be subject to change.)
Each Debian package is assigned a priority by the distribution maintainers, as an aid to the package management system. The priorities are:
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
not even be able to use dpkg
to restore things. Systems with only
the Required packages are probably inadequate for most purposes, but they do
have enough functionality to allow the sysadmin to boot and install more
software.
Other packages without which the system will not run well or be usable will carry this priority. This does not include Emacs or X11 or TeX or any other large applications. These packages only constitute the bare infrastructure.
This is what will install by default if users do not select anything else. "Standard" does not include many large applications, but it does include Emacs (this is more a piece of infrastructure than an application) and a reasonable subset of TeX and LaTeX (if this turns out to be possible without X).
This includes X11, a full TeX distribution, and lots of applications.
Please note the differences among "Priority: required",
"Section: base" and "Essential: yes" in the package
description. "Section: base" means that this package is installed
before everything else on a new system. Most of the packages in "Section:
base" have the "Priority: required" or at least "Priority:
important", and many of them are tagged with "Essential: yes".
"Essential: yes" means that this package requires to specify an extra
force option to the package management system such as dpkg
when
removing from the system. For example, libc6
, mawk
,
and makedev
are "Priority: required" and "Section:
base" but are not "Essential: yes".
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 either
one should therefore satisfy any dependency of a program that requires 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, exim
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 has a mechanism so that, if more than one package which provides the
same virtual package is installed on a system, the system administrator can set
one as the preferred package. The relevant command is
update-alternatives
, and is described further in Alternative commands, Section
6.5.3.
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:
More detailed information on the use of each these terms can be found in the Packaging Manual and the Policy Manual.
Note that dselect
has more fine-grained control over packages
specified by recommends and suggests than
apt-get
, which simply pulls all the packages specified by
depends and leaves all the packages specified by
recommends and suggests. Both programs in
modern form use APT as their back end.
"Pre-depends" is a special dependency. In the case of an ordinary
package, 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. Unpacking basically means that dpkg
will extract the files from the archive file that were meant to be installed on
your filesystem, 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, there are some packages that dpkg
will refuse even to
unpack until certain dependencies are resolved. Such packages are said to
"pre-depend" on the presence of some other package(s). 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., for packages with
"required" priority and their libc dependency.
Once again, more detailed information about this can be found in the Packaging Manual.
Package status can be "unknown", "install",
"remove", "purge", or "hold". These
"want" flags indicate what the user wanted to do with a package
(either by making choices in the "Select" section of
dselect
, or by directly invoking dpkg
).
Their meanings are:
There are two mechanisms for holding back packages from an upgrade, through
dpkg
, or, beginning with Woody, through APT.
With dpkg
, first export the list of package selections:
dpkg --get-selections \* > selections.txt
Then edit the resulting file selections.txt
, changing
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
Or, if you know the package name to hold, simply run:
echo libc6 hold | dpkg --set-selections
This procedure holds packages at the install process of each package file.
The same effect can be obtained through dselect
. Simply 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 take effect immediately after you
exit the [S]elect screen.
The APT system in the Woody distribution has a new alternative mechanism for
holding packages during the archive retrieval process using
Pin-Priority. See the manual page
apt_preferences(5)
, along with http://www.debian.org/doc/manuals/apt-howto/
or the apt-howto
package; Overview of
/etc/apt/preferences
, Section 6.2.8 also contains a brief
explanation.
Source packages are distributed in a directory called source
, and
you can either download them manually, or use
apt-get source foo
to fetch them (see the apt-get(8)
manual page on how to set up APT
for doing that).
For a package foo, 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 a Debian native package).
Once you have them, if you have the dpkg-dev
package installed,
the command
$ dpkg-source -x foo_version-revision.dsc
will extract the package into a directory called foo-version.
Issue the following command to build the binary package:
$ cd foo-version $ su -c "apt-get update ; apt-get install fakeroot" $ dpkg-buildpackage -rfakeroot -us -uc
Then,
# su -c "dpkg -i ../foo_version-revision_arch.deb"
to install the newly built package. See Port a package to the stable system, Section 6.4.10.
For detailed information on creating new packages, read the New
Maintainers' Guide, available in the maint-guide
package, or
at http://www.debian.org/doc/manuals/maint-guide/
.
One of Debian's goals is to provide a consistent upgrade path and a secure upgrade process, and we always do our best to make a new release smoothly upgradable from the previous ones. Packages will alert the user when there are important notices during the upgrade process, and will often provide a solution to a possible problem.
You should also read the Release Notes, the document that describes the details
of specific upgrades, shipped on all Debian CDs, and available on the WWW at
http://www.debian.org/releases/stable/releasenotes
or http://www.debian.org/releases/testing/releasenotes
.
A practical guide to upgrades is provided in Debian package management, Chapter 6. This section describes the fundamental details.
One can always simply execute an anonymous FTP or wget
call to a
Debian archive, peruse the directories until one finds a desired file, fetch
it, and finally install it using dpkg
. (Note that
dpkg
will install upgrade files in place, even on a running
system.) Sometimes, however, a revised package will require the installation of
a newly revised version of another package, in which case the installation will
fail until/unless the other package is installed.
Many people find this manual approach much too time-consuming, since Debian evolves so quickly—typically, a dozen or more new packages are uploaded every week. This number is larger just before a new major release. To deal with this avalanche, many people prefer to use an automated program for upgrading. Several specialized package management tools are available for this purpose.
The Debian package management system has two objectives: the manipulation of
the package file itself and the retrieval of package files from the Debian
archive. dpkg
performs the former task, APT and
dselect
the latter.
dpkg
This is the main program for manipulating package files; read
dpkg(8)
for a full description.
dpkg
comes with several primitive supplemental programs.
dpkg-deb
: Manipulate .deb files.
dpkg-deb(1)
dpkg-ftp
: An older package file retrieval command.
dpkg-ftp(1)
dpkg-mountable
: An older package file retrieval command.
dpkg-mountable(1)
dpkg-split
: Splits a large package into smaller files.
dpkg-split(1)
dpkg-ftp
and dpkg-mountable
have been superseded by
the introduction of the APT system.
APT (the Advanced Packaging Tool) is an advanced interface to the Debian
packaging system consisting of several programs whose names typically begin
with "apt-". apt-get
, apt-cache
and
apt-cdrom
are the command-line tools for handling packages. These
also function as the user's "back end" programs to other tools, such
as dselect
and aptitude
.
For more information, install the apt
package and read
apt-get(8)
, apt-cache(8)
, apt-cdrom(8)
,
apt.conf(5)
, sources.list(5)
,
apt_preferences(5)
(Woody), and
/usr/share/doc/apt/guide.html/index.html
.
An alternative source of information is the APT HOWTO
. This
can be installed by apt-howto
at
/usr/share/doc/Debian/apt-howto/
.
apt-get upgrade and apt-get dist-upgrade pull only
the packages listed under "Depends:" and overlook all the packages
listed under "Recommends:" and "Suggests:". To avoid this,
use dselect
.
dselect
This program is a menu-driven user interface to the Debian package management
system. It is particularly useful for first-time installations and large-scale
upgrades. See dselect
,
Section 6.2.3.
For more information, install the install-doc
package and read
/usr/share/doc/install-doc/dselect-beginner.en.html
or dselect
Documentation for Beginners
.
The kernel (filesystem) in Debian systems supports replacing files even while they're being used.
We also provide a program called start-stop-daemon
which is used
to start daemons at boot time or to stop daemons when the kernel runlevel is
changed (e.g., from multiuser to single-user or to "halt"). The same
program is used by installation scripts when a new package containing a daemon
is installed, to stop running daemons, and to restart them as necessary.
Note that the Debian system does not require use of the single-user mode to upgrade a running system.
If you have manually downloaded package files to your disk (which is not
absolutely necessary, see above for the description of dpkg-ftp
or
APT), then after you have installed the packages, you can remove the
.deb files from your system.
If APT is used, these files are cached in the
/var/cache/apt/archives
directory. You may erase them after
installation (apt-get clean) or copy them to another machine's
/var/cache/apt/archives
directory to save downloading during
subsequent installations.
dpkg
keeps a record of the packages that have been unpacked,
configured, removed, and/or purged, but does not (currently) keep a log of
terminal activity that occurred while a package was being so manipulated.
The simplest way to work around this is to run your dpkg
,
dselect
, apt-get
, etc., sessions within the
script(1)
program.
init
program
Like all Unices, Debian boots up by executing the program init
.
The configuration file for init
(which is
/etc/inittab
) specifies that the first script to be executed
should be /etc/init.d/rcS
. This script runs all of the scripts in
/etc/rcS.d/
by sourcing or forking a subprocess depending on their
file extension to perform initialization such as checking and mounting file
systems, loading modules, starting the network services, setting the clock,
etc. Then, for compatibility, it also runs the files (except those with a `.'
in the filename) in /etc/rc.boot/
. Any scripts in the latter
directory are usually reserved for system administrator use, and using them in
packages is deprecated. See System
initialization, Section 9.1 and System
run levels and init.d scripts
in the Debian Policy Manual for more
info.
After completing the boot process, init
executes all start scripts
in a directory specified by the default runlevel (this runlevel is given by the
entry for id in /etc/inittab
). Like most System V
compatible Unices, Linux has 7 runlevels:
Debian systems come with id=2, which indicates that the default
runlevel will be 2 when the multiuser state is entered, and the scripts in
/etc/rc2.d/
will be run.
In fact, the scripts in any of the directories
/etc/rcN.d/
are just symbolic links back to scripts in
/etc/init.d/
. However, the names of the files in
each of the /etc/rcN.d/
directories are selected to
indicate the way the scripts in /etc/init.d/
will
be run. Specifically, before entering any runlevel, all the scripts beginning
with `K' are run; these scripts kill services. Then all the scripts beginning
with `S' are run; these scripts start services. The two-digit number following
the `K' or `S' indicates the order in which the script is run. Lower-numbered
scripts are executed first.
This approach works because the scripts in /etc/init.d/
all take
an argument which can be either "start", "stop",
"reload", "restart" or "force-reload" and will
then do the task indicated by the argument. These scripts can be used even
after a system has been booted, to control various processes.
For example, with the argument "reload" the command
# /etc/init.d/sendmail reload
sends the sendmail daemon a signal to reread its configuration file.
Debian does not use a BSD-style rc.local directory to customize the boot process; instead it provides the following mechanism for customization.
Suppose a system needs to execute script foo on startup, or on entry to a particular (System V) runlevel. Then the system administrator should:
/etc/init.d/
.
update-rc.d
with appropriate arguments, to
set up links between the (command-line-specified) directories
rc?.d and /etc/init.d/foo
. Here,
? is a number from 0 through 6 that corresponds to one of the System
V runlevels.
The command update-rc.d
will set up links between files in the
directories rc?.d and the script in
/etc/init.d/
. Each link will begin with an `S' or a `K', followed
by a number, followed by the name of the script. When the system enters a
runlevel N, scripts beginning with `K' in
/etc/rcN.d/
are executed with stop as
their argument, followed by those beginning with `S' in
/etc/rcN.d/
with start as their argument.
One might, for example, cause the script foo to execute at
boot-up, by putting it in /etc/init.d/
and installing the links
with update-rc.d foo defaults 19. The argument
defaults refers to the default runlevels, which are 2 through 5.
The argument 19 ensures that foo is called before any
scripts containing numbers 20 or larger.
Debian offers several avenues to accommodate any wishes of the system administrator without breaking the system.
dpkg-divert
, see The
dpkg-divert
command, Section 6.5.1.
equivs
, see The
equivs
package, Section 6.5.2.
update-alternative
, see Alternative commands, Section
6.5.3.
make-kpkg
can accommodate many boot loaders. See
make-kpkg(1)
and Debian standard method, Section
7.1.1.
Any files under /usr/local/
belong to the system administrator and
Debian will not touch them. Most (or all) files under /etc
are
conffiles and Debian will not overwrite them upon upgrade unless
the system administrator requests so explicitly.
The Debian system is internationalized and provides support for character display and entry in many languages, both within the console and under X. Many documents, manual pages, and system messages have been translated into a growing number of languages. During installation, Debian prompts the user to choose an installation language (and sometimes a local language variant).
If your installed system does not support all the language features you need, or if you need to change languages or install a different keyboard to support your language, see Localization, Section 9.7.
See The Linux kernel under Debian, Chapter 7.
One has to understand the Debian policy with respect to headers.
The Debian C libraries are built with the most recent stable releases of the kernel headers.
For example, the Debian-1.2 release used version 5.4.13 of the headers. This
practice contrasts with the Linux kernel source packages distributed at all
Linux FTP archive sites, which use even more recent versions of the headers.
The kernel headers distributed with the kernel source are located in
/usr/include/linux/include/
.
If you need to compile a program with kernel headers that are newer than those
provided by libc6-dev
, then you must add
-I/usr/src/linux/include/ to your command line when compiling.
This came up at one point, for example, with the packaging of the automounter
daemon (amd
). When new kernels changed some internals dealing
with NFS, amd
needed to know about them. This required the
inclusion of the latest kernel headers.
Users who wish to (or must) build a custom kernel are encouraged to download
the package kernel-package
. This package contains the script to
build the kernel package, and provides the capability to create a Debian
kernel-image package just by running the command
# make-kpkg kernel_image
in the top-level kernel source directory. Help is available by executing the command
# make-kpkg --help
and through the manual page make-kpkg(8)
and The Linux kernel under Debian, Chapter 7.
Users must separately download the source code for the most recent kernel (or
the kernel of their choice) from their favorite Linux archive site, unless a
kernel-source-version package is available (where version
stands for the kernel version). The Debian initrd
boot script
requires a special kernel patch called initrd
; see http://bugs.debian.org/149236
.
Detailed instructions for using the kernel-package
package are
given in the file /usr/share/doc/kernel-package/README.gz
.
To employ alternative boot loaders such as grub
or
loadlin
, copy the compiled Linux kernel bzimage
to
other locations (e.g., to /boot/grub
or to an MS-DOS partition).
The task of making a custom boot floppy is greatly aided by the Debian package
boot-floppies
, normally found in the admin section of
the Debian FTP archive. Shell scripts in this package produce boot floppies in
syslinux
format. These are MS-DOS formatted floppies whose master
boot records have been altered so that they directly boot Linux (or whatever
other operating system has been defined in the syslinux.cfg
file
on the floppy). Other scripts in this package produce emergency root disks and
can even reproduce the base disks.
You will find more information about this in the
/usr/doc/boot-floppies/README
file after installing the
boot-floppies
package.
Debian's modconf
package provides a shell script
(/usr/sbin/modconf
) which can be used to customize the
configuration of modules. This script presents a menu-based interface,
prompting the user for particulars on the loadable device drivers in his
system. The responses are used to customize the file
/etc/modules.conf
(which lists aliases, and other arguments that
must be used in conjunction with various modules) through files in
/etc/modutils/
, and /etc/modules
(which lists the
modules that must be loaded at boot time).
Like the (new) Configure.help
files that are now available to
support the construction of custom kernels, the modconf
package
comes with a series of help files (in /usr/share/modconf/
) which
provide detailed information on appropriate arguments for each of the modules.
See The modularized 2.4 kernel,
Section 7.2 for examples.
The kernel-image-NNN.prerm
script checks to see whether
the kernel you are currently running is the same as the kernel you are trying
to de-install. Therefore you can safely remove unwanted kernel image packages
using this command:
dpkg --purge --force-remove-essential kernel-image-NNN
(Replace NNN with your kernel version and revision number, of course.)
Debian Reference
1.07-1, Sun Mar 7 15:48:58 UTC 2004osamu@debian.org
dsewell@virginia.edu