這一章節是針對非開發者說明 Debian 系統的原理。想要了解更細微詳盡的訊息,請參閱:
以上文件均列在 參考資料, 第 15.1 節。
如果您在尋找比較淺顯易懂的 "how-to",請直接跳到 Debian 套件管理系統, 第 6 章 或其他相關的章節。
本節的寫作是基於 "Debian FAQ" 改寫,適合當作一般 Debian 系統管理者的起步文件。
每個被包裝好的 Debian 套件可以從其中一個 Debian mirror site
映射站台透過 FTP 或 HTTP 取得。
以下的目錄皆可在 Debian 映射站台中的 debian
目錄找到:
dists/
:Packages.gz
仍然存放在這裡。
pool/
:tools/
:doc/
:indices/
:project/
:project/experimental/
:project/orphaned/
:
stable distribution 套件的入口,Debian Sarge (3.1r0),被登記到
stable
(符號鏈接指向 sarge/
目錄):
stable版本(Debian Sarge
(3.1r0))的stable
(連結到sarge/
)目錄下紀錄了不同的套件總件:
stable/main/
: 該目錄包含了最近發行的 Debian 系統的套件版本。
這些套件均遵循 Debian Free Software
Guidelines (DFSG)
(它位於
/usr/share/doc/debian/social-contract.txt
需安裝
debian-doc
),它們均可以自由使用和散布。
stable/non-free/
: 經過 DFSG 的驗證而無法稱為 free
的套件皆放在該目錄下。
例如,有些套件的許可證條款 (licenses) 禁止其用於商業的 distribution。有些雖可以再散布,但本身是共享軟件而非自由軟件。
stable/contrib/
:這部份的軟體本身是 DFSG-free
但由於某些原因使得必須依賴非 DFSG-free 的軟體才能安裝使用。
除了上述的目錄外,實體套件存在的位置為 pool
目錄(pool
目錄, 第 2.1.10 節)。
現階段 stable 版本的臭蟲報告均列在 Stable
Problems
網頁上。
testing distribution 的套件入口,Debian Etch,在
unstable 中通過某種程度的測試後會登記到 testing
(符號鏈接指向 etch/
)
目錄。現在,除了上述目錄,新上載的套件的實體儲存位置為 pool
目錄
(pool
目錄, 第 2.1.10 節)。在
testing/
下同樣有 main
, contrib
,和
non-free
子目錄,它們的作用與 stable/
中的一樣。
這些套件必須可以同時運行於所有架構並且能正常安裝。比起在 unstable
中的對應版本,它們必需有更少的 release-critical 錯誤。這個種方式,我們將
testing 視為更接近發行的候選版本。有關 testing
機制的更多資訊請參閱 http://ftp-master.debian.org/testing/
。
testing distribution 的最新消息發佈在下列站台:
update
excuses
testing
problems
release-critical
bugs
base system
bugs
bugs in standard
and task packages
other bugs and bug-squashing party
notes
unstable distribution 的套件入口,總是被命名為
"Sid",被登記到 unstable
(符號鏈接指向
sid/
) 目錄,上傳至 Debian archive 的套件在被移至
testing/
前就一直放在這兒。新上傳的套件的實體儲存位置為
pool
目錄 (pool
目錄, 第 2.1.10
節)。在 unstable/
下同樣有 main
,
contrib
和 non-free
子目錄, 它們的作用與
stable/
中相同。
unstable distribution 反映了系統最新的開發進展。歡迎廣大用戶使用並測試這些套件,同時也提醒你們這些套件還不完善。使用 unstable distribution 的好處就是你可以獲得 Debian 軟體專案 — 的最新更新,不過新東西也會出新問題,你得好壞兼收 :-)
unstable distribution 的最新臭蟲報告見於 Unstable
Problems
網頁上。
當 testing distribution 足夠成熟了,它便成為
frozen,表示這個版本不再加入新程式,只進行除錯工作。如果需要的話,
dists
目錄中會建立新的 testing 目錄樹,並給予新的開發代號。 frozen
distribution 再經過幾個月的測試、更新、再凍結也稱之為“循環測試”。(最近的
Woody 發佈進程沒有建立 frozen/
的符號鏈接,所以
frozen 並不算 distribution,僅是 testing distribution
的一個開發階段。)
我們將 frozen distribution 中可能延遲套件或整個版本發佈的錯誤都記錄在案,一但錯誤總數低於可接受的最大值,frozen distribution 就晉升成 stable,而新版本發布了,前一個 stable distribution 成為過期版 (obsolete) (並被移至相對應的目錄)。
存在於 dists
目錄下的實體目錄名稱,例如 sarge/
和
etch/
,就是 "開發代號 (codenames)"。當某個 Debian
distribution
處於開發階段,它並沒有版本號碼,取而代之的是開發代號。使用開發代號的目的在於簡化建立
Debian distributions 映射站台的工作(如果真實目錄例如 unstable
突然改名為 stable/
,許多文件都沒必要再次下載)。
現在,stable 是一個指向 Sarge 的符號鏈接,testing 是指向 Etch 的符號鏈接。也就是說 Sarge 是當前的 stable distribution, Etch 是當前的 testing distribution。
unstable/
distribution 是指向 sid/
的永久符號鏈接,即
unstable distribution 總是稱為 Sid 。
已使用過的開發代號有: "Buzz" 用在 release 1.1 , "Rex" 用在 release 1.2 , "Bo" 用在releases 1.3.x , "Hamm" 用在 release 2.0 , "Slink" 用在 release 2.1 , "Potato" 用在 release 2.2 , "Woody" 用在 release 3.0 和 "Sarge" 用在 release 3.1 。
到目前為止它們均出自 Pixar 的電影 玩具總動員 (Toy Story) 。
pool
目錄
過去,套件均放在 dists
目錄下相應的 distribution
子目錄中。這種做法產生了許多問題,例如映射站台進行新版本發佈時大量頻寬被消耗。
現在套件均依原本的套件名稱分類放進一個巨大的池子 "pool"。為了方便管理, pool 目錄下按屬性再分類 (main , contrib ,和 non-free),分類下面再按原本的套件名稱的英文字首字母歸檔。這些目錄包含的文件有:運行於各種系統架構的二進位套件,和生成這些二進制套件的源碼套件。
你可以執行命令 apt-cache showsrc mypackagename ,查看
"Directory:" 行獲知每個套件的存放位置。例如:apache
套件存放在 pool/main/a/apache/
。因為 lib*
的套件數量龐大,它們以特殊的方式歸檔:例如,libpaper
套件存放在
pool/main/libp/libpaper/
。
諸如 apt
等命令訪問的索引文件仍位於 dists
目錄中。而且,直到本文寫作之時,舊的 distributions 套件還沒轉到 pool
目錄,所以你將看到路徑中的 "Directory" 標頭欄中包含有 distribution
名稱如 potato 或 woody。
通常,你大可不必注意這些事情,新版的 apt
和舊版
dpkg-ftp
會自動處理它們。想了解更多資訊,參閱 RFC:
implementation of package pools
。
過去 Sid 並不存在, Debian archive 組織有一個主要的工作流程:它假設當前
unstable 中建立了某個軟體開發項目,它會在整個 distribution
形成一個新的 stable/
時發佈。但是因為很多軟體不是用這個方式在開發,所以一但軟體要發佈時,就必需把整個目錄都搬移到
stable 下。因為在搬移目錄時會用掉大量的頻寬,所以這個流程就顯得很不切實際。
經過幾年的研究摸索,archive 管理員提出一個方案,將未發佈的二進位檔放在一個名為 sid 的特定目錄。由於這些軟體尚未發佈,從那時起,它們就被加入到 unstable 目錄樹。當它們首次發布時,將會建立一個從當前 stable 指向 sid 的鏈接。這個方案的確會使使用者覺得困惑。
有了套件 pool 的幫助(參閱 pool
目錄, 第 2.1.10
節),在 woody distribution
開發過程中,二進位套件均按一定規範存放於 pool 目錄,而與 distribution
無關,當發佈新版本時,就不會再出現大量頻寬被消耗的問題。(不過,開發過程還是會用掉大量頻寬)。
incoming
中的上傳套件
上載的套件在經確認它們是由 Debian 開發者上載的後,會先存放於 http://incoming.debian.org/
(對於那些無維護者上載(Non-Maintainer Upload (NMU))的套件則放入
DELAYED
子目錄)。會有一天,它們將從 incoming/
移入
unstable/
。
在緊急情況下,你可能會等不及它們移入 unstable/
而直接從
incoming.
中下載安裝。
最新的 Debian distribution 存放在任何一個 Debian mirror site
的 debian
目錄下。舊版本的 Debian 如 Slink 存放在 http://archive.debian.org/
或
Debian 映射站台的 debian-archive
目錄下。
舊的 testing 和 unstable 套件存放在 http://snapshot.debian.net/
。
在每個主要目錄樹下(dists/stable/main
、
dists/stable/contrib
、 dists/stable/non-free
、
dists/unstable/main/
等)按晶片架構又分了子目錄,每個子目錄中存放著在該晶片架構下編譯的二進位套件。
binary-all/
,存放與架構無關的套件,如 Perl script、純文件等。
binary-platform/
,存放運行於該平台的二進制套件。
請注意,testing 和 unstable
的二進位套件不再存放在這些目錄中,而是放在最上層 pool
目錄中。但為了向下相容,所以在目錄中仍保留有索引文件(Packages
和
Packages.gz
)。
要獲得實際上的二進制架構技術支持,請參閱各發行版的發佈記錄(Release
Notes)。它們放發佈記錄站台 stable
和
testing
。
Debian 系統中包含了所有東西的源碼,不僅如此,許可證條款規定系統中所有的程式必須和其源碼一起發行,或提供源碼。
通常源碼發佈在 source
目錄,該目錄同時處於所有特定平台的目錄中,或是把更新的源碼放在
pool
目錄中(參閱 pool
目錄, 第
2.1.10 節)。對於不太熟悉 Debian archive 目錄結構的用戶,想獲得源碼可以試試
apt-get source mypackagename 命令。
有些套件,如著名的
pine
,由於許可證限制,只提供源碼套件。(最近,pine-tracker
套件提供了一個簡易的安裝方式。)參閱 把套件引入 stable 系統, 第
6.4.10 節 和 包裝套件, 第 13.10
節 教你如何手動編建一個套件。
contrib
和 non-free
目錄中的套件可能不提供源碼,因為它們不算正式 Debian 系統的一部分。
套件通常包含了實現一系列相關命令或特性的所有必需的檔案。Debian 套件有兩種類型:
使用套件管理系統來安裝套件時會用到由套件維護者建立的"相依資訊"。這些相依資訊記錄在每個套件的
control 文件中。例如,包含 GNU C 編譯器 (gcc
)
的套件"相依"於包含連結器 (linker) 和組譯器 (assembler) 的
binutils
套件。如果用戶試圖在沒有安裝 binutils
的情況下安裝
gcc
,軟件包管理系統(dpkg)就會顯示錯誤信息,告訴你需要安裝
binutils
,並停止安裝 gcc
。(不過,倔強的用戶可以對這個信息視而不見,參閱 dpkg(8)
)。)更多資訊請參閱下面的 Package dependencies, 第 2.2.8
節 。
Debian 套件管理工具可用來:
Debian 的"套件",或是 Debian 保存壓縮檔 (archive) 包含了和特定程式或一組相關的程式有關的可執行檔,函式庫,和文件。通常,Debian 保存壓縮檔是以 .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_ver-rev_arch.deb
where, usually, foo is the package name, ver is the upstream version number, rev is the Debian revision number, and arch is the target architecture. Files are easily renamed, of course. You can find out what package is really contained in any given file of name filename by running the following command:
dpkg --info filename
The Debian revision number is specified by the Debian developer or by whoever built the package. A change in revision number usually indicates that some aspect of the packaging has changed.
Files that are intended to be changeable by the local administrator are kept in
/etc/
. Debian policy dictates that all changes to locally
configurable files be preserved across package upgrades.
If a default version of a locally configurable file is shipped in the package itself then the file is listed as a "conffile". The package management system does not upgrade conffiles that have been changed by the administrator since the package was last installed without getting the administrator's permission. On the other hand, if the conffile has not been changed by the administrator then the conffile will be upgraded along with the rest of the package. This is almost always desirable and so it is advantageous to minimize changes to conffiles.
To list the conffiles belonging to a package run the following command:
dpkg --status package
The list follows the "Conffiles:" line.
For more information about conffiles you can read the section of the Debian Policy Manual entitled "Configuration files". (See 參考資料, 第 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 the need of a program that requires a news reader
on the system in order to be useful. They are therefore both said to Provide
the "virtual package" called news-reader
.
Similarly, many packages such as exim
, exim4
,
sendmail
, and postfix
, 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 that Depends on the installation of a mail transport agent will be
satisfied by the existence of this virtual package.
Debian has a mechanism such 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 指令, 第 6.5.3 節.
The Debian packaging system handles dependency declarations which are used to express the fact that one package requires another package to be installed in order to work or in order to work better.
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.
dpkg
always configures a package upon which another package
Depends before it configures the package that Depends on it. However,
dpkg
normally unpacks archive files in arbitrary order,
independently of dependencies. (Unpacking consists of extracting files from
the archive file and putting them in the right place.) If, however, a package
Pre-Depends on another then the other package is unpacked and
configured before the one that Pre-Depends is even unpacked. [2] The use of this dependency is
kept to a minimum.
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.
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 把套件引入 stable 系統, 第 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 smooth, secure and reliable upgrade
process. The packaging system alerts the administrator to important changes
and sometimes asks the administrator to take decisions. You should also read
the Release Notes; it is shipped on all Debian CDs and is 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 套件管理系統, 第 6 章. This section merely provides an outline, beginning with the packaging tools.
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
,
第 6.2.4 節.
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. When packages are upgraded any services provided by those packages are restarted if they are configured to run in the current runlevel. 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
.
What happens next depends on whether the sysv-rc
package or the
file-rc
package is installed. The following assumes that the
sysv-rc
package is installed. (file-rc
contains its
own /etc/init.d/rcS
script and uses a file instead of symlinks in
rc directories to control which services are started in which runlevels.)
The /etc/init.d/rcS
file from the sysv-rc
package
runs all of the scripts in /etc/rcS.d/
in order to perform
initialization such as checking and mounting file systems, loading modules,
starting the network services, setting the clock, and so on. Then, for
compatibility, it also runs all the files (except those with a `.' in the
filename) in /etc/rc.boot/
. The latter directory is reserved for
system administrator use, and using it is deprecated. See 初始化系統的提示, 第 9.1 節 and
System run
levels and init.d scripts
in the Debian Policy Manual for more info.
Debian does not use a BSD-style rc.local directory.
After completing the boot process, init
starts all services that
are configured to run in the default runlevel. The default runlevel is given
by the entry for id in /etc/inittab
. Debian ships
with id=2.
Debian uses the following runlevels:
Runlevels 7, 8, and 9 can also be used but their rc directories are not populated when packages are installed.
Switch runlevels using the telinit
command.
When entering a runlevel all scripts in
/etc/rcrunlevel.d/
are executed. The first letter in
the name of the script determines the way in which the script
is run: scripts whose names begin with K are run with the argument
stop. Scripts beginning with S are run with the
argument start. The scripts are run in the alphabetical order of
their names; thus "stop" scripts are run before "start"
scripts and the two-digit numbers following the K or
S determine the order in which the scripts are run.
The scripts in /etc/rcrunlevel.d
are in fact just
symbolic links back to scripts in /etc/init.d/
. These scripts
also accept "restart" and "force-reload" as argument; the
latter methods can be used after a system has been booted in order to restart
services or force them to reload their configuration files.
For example:
# /etc/init.d/sendmail force-reload
Customizing runlevels is an advanced system administration task. The following advice holds for most services.
To enable service service in runlevel R create the
symbolic link
/etc/rcR.d/Sxyservice
with target
../init.d/service
. The sequence number xy
should be the sequence number that was assigned to the service when the package
was installed.
The disable the service, rename the symbolic link so that its name begins with a K instead of with an S and its sequence number is 100 minus xy.
It is convenient to use a runlevel editor such as sysv-rc-conf
or
ksysv
for these purposes.
It is possible to delete the S symlink for a service in a
particular runlevel directory instead of renaming it. This does not disable
the service but leaves it in a "floating" state as far as the
sysv-rc
init system is concerned: on runlevel changes the service
will be neither started nor stopped but will be left as it was, whether running
or not running. Note, however, that a service left in such a floating state
will be started if its package is upgraded whether or not it was running before
the upgrade. This is a known shortcoming of the current Debian system. Note
also that you should retain a service's K symlinks in runlevels 0
and 6. If you delete all the symlinks for a service then on upgrade the
service's package will restore the symlinks to their factory default state.
It is not advisable to make any changes to symlinks in
/etc/rcS.d/
.
Debian offers several avenues to accommodate any wishes of the system administrator without breaking the system.
dpkg-divert
, see dpkg-divert
指令, 第
6.5.1 節.
equivs
, see equivs
套件, 第 6.5.2
節.
update-alternative
, see Alternative 指令, 第 6.5.3 節.
make-kpkg
can accommodate many boot loaders. See
make-kpkg(1)
and Debian standard method, 第 7.1.1
節.
Any files under /usr/local/
belong to the system administrator and
Debian will not touch them. Most 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, 第 9.7 節.
See The Linux kernel under Debian, 第 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, 第 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 was greatly aided by the Debian package
boot-floppies
, used to be found in the admin section
of the Debian FTP archive for Potato and older. 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,
第 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 參考手冊
1.07-15, 週五 九月 23 22:05:38 UTC 2004osamu@debian.org
asho@debian.org.tw