[ 上一頁 ] [ 目錄 ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ 13 ] [ 14 ] [ 15 ] [ A ] [ 下一頁 ]

Debian 參考手冊
第 2 章 - Debian 基礎


這一章節是針對非開發者說明 Debian 系統的原理。想要了解更細微詳盡的訊息,請參閱:

以上文件均列在 參考資料, 第 15.1 節

如果您在尋找比較淺顯易懂的 "how-to",請直接跳到 Debian 套件管理系統, 第 6 章 或其他相關的章節。

本節的寫作是基於 "Debian FAQ" 改寫,適合當作一般 Debian 系統管理者的起步文件。


2.1 Debian archives


2.1.1 目錄結構

每個被包裝好的 Debian 套件可以從其中一個 Debian mirror site 映射站台透過 FTP 或 HTTP 取得。

以下的目錄皆可在 Debian 映射站台中的 debian 目錄找到:

dists/
該目錄存放 "distributions",主要是用來取得不同發行版本的套件。有些舊套件或 Packages.gz 仍然存放在這裡。
pool/
所有 Debian releases 及 pre-releases 的套件的新的實體位址。
tools/
建立開機片,分割硬碟,解/壓縮檔案,啟動 Linux 的 DOS 工具程式
doc/
問與答,臭蟲回報等基本 Debian 文件。
indices/
Maintainers file 和 override 檔案。
project/
大多為開發者的資源,例如:
project/experimental/
該目錄存放的套件都是開發中且為 alpha 測試階段。使用者不應抓取這裡的套件,因為這些套件是危險且會對系統造成傷害。
project/orphaned/
維護者不再維護且從發行版本移除的"孤兒"軟體放在該目錄。

2.1.2 Debian distributions

stable distribution 套件的入口,Debian Sarge (3.1r0),被登記到 stable (符號鏈接指向 sarge/ 目錄):


2.1.3 stable 發行版本

stable版本(Debian Sarge (3.1r0))的stable(連結到sarge/)目錄下紀錄了不同的套件總件:

除了上述的目錄外,實體套件存在的位置為 pool 目錄(pool 目錄, 第 2.1.10 節)。

現階段 stable 版本的臭蟲報告均列在 Stable Problems 網頁上。


2.1.4 The testing distribution

testing distribution 的套件入口,Debian Etch,在 unstable 中通過某種程度的測試後會登記到 testing (符號鏈接指向 etch/) 目錄。現在,除了上述目錄,新上載的套件的實體儲存位置為 pool 目錄 (pool 目錄, 第 2.1.10 節)。在 testing/ 下同樣有 maincontrib ,和 non-free 子目錄,它們的作用與 stable/ 中的一樣。

這些套件必須可以同時運行於所有架構並且能正常安裝。比起在 unstable 中的對應版本,它們必需有更少的 release-critical 錯誤。這個種方式,我們將 testing 視為更接近發行的候選版本。有關 testing 機制的更多資訊請參閱 http://ftp-master.debian.org/testing/

testing distribution 的最新消息發佈在下列站台:


2.1.5 The unstable distribution

unstable distribution 的套件入口,總是被命名為 "Sid",被登記到 unstable (符號鏈接指向 sid/) 目錄,上傳至 Debian archive 的套件在被移至 testing/ 前就一直放在這兒。新上傳的套件的實體儲存位置為 pool 目錄 (pool 目錄, 第 2.1.10 節)。在 unstable/ 下同樣有 maincontribnon-free 子目錄, 它們的作用與 stable/ 中相同。

unstable distribution 反映了系統最新的開發進展。歡迎廣大用戶使用並測試這些套件,同時也提醒你們這些套件還不完善。使用 unstable distribution 的好處就是你可以獲得 Debian 軟體專案 — 的最新更新,不過新東西也會出新問題,你得好壞兼收 :-)

unstable distribution 的最新臭蟲報告見於 Unstable Problems 網頁上。


2.1.6 The frozen distribution

testing distribution 足夠成熟了,它便成為 frozen,表示這個版本不再加入新程式,只進行除錯工作。如果需要的話, dists 目錄中會建立新的 testing 目錄樹,並給予新的開發代號。 frozen distribution 再經過幾個月的測試、更新、再凍結也稱之為“循環測試”。(最近的 Woody 發佈進程沒有建立 frozen/ 的符號鏈接,所以 frozen 並不算 distribution,僅是 testing distribution 的一個開發階段。)

我們將 frozen distribution 中可能延遲套件或整個版本發佈的錯誤都記錄在案,一但錯誤總數低於可接受的最大值,frozen distribution 就晉升成 stable,而新版本發布了,前一個 stable distribution 成為過期版 (obsolete) (並被移至相對應的目錄)。


2.1.7 Debian distribution 開發代號 (codenames)

存在於 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 。


2.1.8 已用過的開發代號

已使用過的開發代號有: "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 。


2.1.9 開發代號的來源

到目前為止它們均出自 Pixar 的電影 玩具總動員 (Toy Story)


2.1.10 pool 目錄

過去,套件均放在 dists 目錄下相應的 distribution 子目錄中。這種做法產生了許多問題,例如映射站台進行新版本發佈時大量頻寬被消耗。

現在套件均依原本的套件名稱分類放進一個巨大的池子 "pool"。為了方便管理, pool 目錄下按屬性再分類 (maincontrib ,和 non-free),分類下面再按原本的套件名稱的英文字首字母歸檔。這些目錄包含的文件有:運行於各種系統架構的二進位套件,和生成這些二進制套件的源碼套件。

你可以執行命令 apt-cache showsrc mypackagename ,查看 "Directory:" 行獲知每個套件的存放位置。例如:apache 套件存放在 pool/main/a/apache/ 。因為 lib* 的套件數量龐大,它們以特殊的方式歸檔:例如,libpaper 套件存放在 pool/main/libp/libpaper/

諸如 apt 等命令訪問的索引文件仍位於 dists 目錄中。而且,直到本文寫作之時,舊的 distributions 套件還沒轉到 pool 目錄,所以你將看到路徑中的 "Directory" 標頭欄中包含有 distribution 名稱如 potatowoody

通常,你大可不必注意這些事情,新版的 apt 和舊版 dpkg-ftp 會自動處理它們。想了解更多資訊,參閱 RFC: implementation of package pools


2.1.11 sid 的歷史記錄

過去 Sid 並不存在, Debian archive 組織有一個主要的工作流程:它假設當前 unstable 中建立了某個軟體開發項目,它會在整個 distribution 形成一個新的 stable/ 時發佈。但是因為很多軟體不是用這個方式在開發,所以一但軟體要發佈時,就必需把整個目錄都搬移到 stable 下。因為在搬移目錄時會用掉大量的頻寬,所以這個流程就顯得很不切實際。

經過幾年的研究摸索,archive 管理員提出一個方案,將未發佈的二進位檔放在一個名為 sid 的特定目錄。由於這些軟體尚未發佈,從那時起,它們就被加入到 unstable 目錄樹。當它們首次發布時,將會建立一個從當前 stable 指向 sid 的鏈接。這個方案的確會使使用者覺得困惑。

有了套件 pool 的幫助(參閱 pool 目錄, 第 2.1.10 節),在 woody distribution 開發過程中,二進位套件均按一定規範存放於 pool 目錄,而與 distribution 無關,當發佈新版本時,就不會再出現大量頻寬被消耗的問題。(不過,開發過程還是會用掉大量頻寬)。


2.1.12 在 incoming 中的上傳套件

上載的套件在經確認它們是由 Debian 開發者上載的後,會先存放於 http://incoming.debian.org/ (對於那些無維護者上載(Non-Maintainer Upload (NMU))的套件則放入 DELAYED 子目錄)。會有一天,它們將從 incoming/ 移入 unstable/

在緊急情況下,你可能會等不及它們移入 unstable/ 而直接從 incoming. 中下載安裝。


2.1.13 找回舊套件

最新的 Debian distribution 存放在任何一個 Debian mirror sitedebian 目錄下。舊版本的 Debian 如 Slink 存放在 http://archive.debian.org/ 或 Debian 映射站台的 debian-archive 目錄下。

舊的 testingunstable 套件存放在 http://snapshot.debian.net/


2.1.14 Architecture sections

在每個主要目錄樹下(dists/stable/maindists/stable/contribdists/stable/non-freedists/unstable/main/ 等)按晶片架構又分了子目錄,每個子目錄中存放著在該晶片架構下編譯的二進位套件。

請注意,testingunstable 的二進位套件不再存放在這些目錄中,而是放在最上層 pool 目錄中。但為了向下相容,所以在目錄中仍保留有索引文件(PackagesPackages.gz)。

要獲得實際上的二進制架構技術支持,請參閱各發行版的發佈記錄(Release Notes)。它們放發佈記錄站台 stabletesting


2.1.15 源碼

Debian 系統中包含了所有東西的源碼,不僅如此,許可證條款規定系統中所有的程式必須和其源碼一起發行,或提供源碼。

通常源碼發佈在 source 目錄,該目錄同時處於所有特定平台的目錄中,或是把更新的源碼放在 pool 目錄中(參閱 pool 目錄, 第 2.1.10 節)。對於不太熟悉 Debian archive 目錄結構的用戶,想獲得源碼可以試試 apt-get source mypackagename 命令。

有些套件,如著名的 pine,由於許可證限制,只提供源碼套件。(最近,pine-tracker 套件提供了一個簡易的安裝方式。)參閱 把套件引入 stable 系統, 第 6.4.10 節包裝套件, 第 13.10 節 教你如何手動編建一個套件。

contribnon-free 目錄中的套件可能不提供源碼,因為它們不算正式 Debian 系統的一部分。


2.2 Debian 套件管理系統


2.2.1 Debian 套件概觀

套件通常包含了實現一系列相關命令或特性的所有必需的檔案。Debian 套件有兩種類型:

使用套件管理系統來安裝套件時會用到由套件維護者建立的"相依資訊"。這些相依資訊記錄在每個套件的 control 文件中。例如,包含 GNU C 編譯器 (gcc) 的套件"相依"於包含連結器 (linker) 和組譯器 (assembler) 的 binutils 套件。如果用戶試圖在沒有安裝 binutils 的情況下安裝 gcc,軟件包管理系統(dpkg)就會顯示錯誤信息,告訴你需要安裝 binutils,並停止安裝 gcc 。(不過,倔強的用戶可以對這個信息視而不見,參閱 dpkg(8) )。)更多資訊請參閱下面的 Package dependencies, 第 2.2.8 節

Debian 套件管理工具可用來:


2.2.2 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.


2.2.3 Naming conventions for Debian package filenames

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.


2.2.4 Preservation of local configuration

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 節).


2.2.5 Debian maintenance scripts

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:

preinst
This script executes before its package is 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 a package once it 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 reconfigure the 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 a package, and/or removes files created by it. (Also see Virtual packages, 第 2.2.7 節.)

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.)


2.2.6 Package priorities

Each Debian package is assigned a priority by the distribution maintainers, as an aid to the package management system. The priorities are:

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".


2.2.7 Virtual packages

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 節.


2.2.8 Package dependencies

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.


2.2.9 The meaning of "Pre-Depends"

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.


2.2.10 Package status

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:


2.2.11 Holding back packages from an upgrade

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.


2.2.12 Source packages

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).


2.2.13 Building binary packages from a source package

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 節.


2.2.14 Creating new Debian packages

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/.


2.3 Upgrading a Debian system

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.


2.3.1 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-ftp and dpkg-mountable have been superseded by the introduction of the APT system.


2.3.2 APT

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.


2.3.3 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.


2.3.4 Upgrading a running system

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.


2.3.5 Downloaded and cached .deb archive files

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.


2.3.6 Record-keeping for upgrades

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.


2.4 The Debian boot process


2.4.1 The 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.


2.4.2 Runlevels

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

2.4.3 Customizing runlevels

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/.


2.5 Supporting diversity

Debian offers several avenues to accommodate any wishes of the system administrator without breaking the system.

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.


2.6 Internationalization

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 節.


2.7 Debian and the kernel

See The Linux kernel under Debian, 第 7 章.


2.7.1 Compiling a kernel from non-Debian source

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.


2.7.2 Tools to build custom kernels

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.


2.7.3 Alternative boot loaders

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).


2.7.4 Custom boot floppies

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.


2.7.5 Special provisions for dealing with modules

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.


2.7.6 De-installing an old kernel package

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.)


[ 上一頁 ] [ 目錄 ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ 13 ] [ 14 ] [ 15 ] [ A ] [ 下一頁 ]

Debian 參考手冊

1.07-15, 週五 九月 23 22:05:38 UTC 2004

青木 修 (Osamu Aoki) osamu@debian.org
翻譯者:葉信佑 (Shine-Yoh Yeh) asho@debian.org.tw
作者, 第 A.1 節