[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Japanese translation of Debian FAQ
customizing.ja.sgml です。
--
関戸 幸一 <sekido@xxxxxxxxxxxxxx>
<!--
<chapt id="customizing">Customizing your installation of &debian;
-->
<chapt id="customizing">&debian; のインストールをカスタマイズする
<!--
<sect id="papersize">How can I ensure that all programs use the same
paper size?
-->
<sect id="papersize">全てのプログラムが確実に同じ用紙サイズを使うように
設定するにはどうすればいいのですか?
<!--
<p>The file <tt>/etc/papersize</tt> contains the name of the system-wide
default paper size (i.e. letter or A4). It can be overwritten using
the <tt>PAPERSIZE</tt> environment variable. For details see the
manual page <tt>papersize(5)</tt>.
-->
<p>ファイル <tt>/etc/papersize</tt> にはシステムのデフォルト用紙サイズの
名前 (すなわち letter や A4) が書かれています。これは環境変数
<tt>PAPERSIZE</tt> を使って上書きすることができます。詳しくは
<tt>papersize(5)</tt> のマニュアルページを見て下さい。
<!--
<sect id="hardwareaccess">How can I provide access to hardware peripherals,
without compromising security?
-->
<sect id="hardwareaccess">セキュリティを弱めることなしにハードウェア機器
にアクセスするにはどうしたらよいですか?
<!--
<p>Many device files in the <tt>/dev</tt> directory belong to some
predefined groups. For example, <tt>/dev/fd0</tt> belongs to the
<tt>floppy</tt> group, and <tt>/dev/dsp</tt> belongs to the
<tt>audio</tt> group.
-->
<p><tt>/dev</tt> ディレクトリにある多くのデバイスファイルは予め定義され
た何らかのグループに属しています。例えば <tt>/dev/fd0</tt> は
<tt>floppy</tt> グループに属しており、<tt>/dev/dsp</tt> は
<tt>audio</tt> グループに属しています。
<!--
<p>If you want a certain user to have access to one of these devices, just
add the user to the group the device belongs to, i.e. do:
<example>adduser user group</example>
This way you won't have to chmod the device file.
-->
<p>あるユーザがこれらのデバイスの一つにアクセスできるようにするには、そ
のデバイスが属するグループにそのユーザを加えれば結構です。つまり
<example>adduser user group</example>
とします。こうすればデバイスファイルを chmod する必要はありません。
<!--
<sect id="consolefont">How do I load a console font on startup the Debian way?
-->
<sect id="consolefont">スタートアップ時にコンソールフォントを Debian 流
にロードするにはどうしたらよいですか?
<!--
<p>The <package/kbd/ and <package/console-tools/ packages support this,
edit <tt>/etc/kbd/config</tt> or <tt>/etc/console-tools/config</tt> files.
-->
<p><package/kbd/ と <package/console-tools/ パッケージがこれをサポートし
ています。<tt>/etc/kbd/config</tt> あるいは
<tt>/etc/console-tools/config</tt> ファイルを編集してください。
<!--
<sect id="appdefaults">How can I configure an X11 program's application
defaults?
-->
<sect id="appdefaults">X11 プログラムのアプリケーションデフォルトを設定
するにはどうすればいいのですか?
<!--
<p>Debian's X11 installation expects you to leave the files in
<tt>/usr/X11R6/lib/X11/app-defaults/</tt> unchanged. If you want to
customise X applications globally, put your customizations in
<tt>/etc/X11/Xresources</tt>. This file is marked as a configuration
file, so its contents will be preserved during upgrades.
-->
<p>Debian の X11 インストールは、ユーザが
<tt>/usr/X11R6/lib/X11/app-defaults/</tt> の中のファイルを変更しないこと
を想定しています。もし X アプリケーションを全体的にカスタマイズしたけれ
ば <tt>/etc/X11/Xresources</tt> をカスタマイズして下さい。このファイル
は設定ファイルとして登録されているので、パッケージをアップグレードしても
その内容は保存されます。
<!--
<sect id="booting">Every distribution seems to have a different boot-up
method. Tell me about Debian's.
-->
<sect id="booting">どのディストリビューションもそれぞれ起動方法が異なっ
ているようですね。Debian の場合について教えて下さい。
<!--
<p>Like all Unices, Debian boots up by executing the program <tt>init</tt>.
The configuration file for <tt>init</tt> (which is <tt>/etc/inittab</tt>)
specifies that the first script to be executed should
be <tt>/etc/init.d/rcS</tt>. This script checks and mounts file systems,
loads modules, starts the network services, sets the clock, performs other
initialization, and then runs all of the scripts (except those with a `.'
in the filename) in <tt>/etc/rc.boot/</tt>. Any scripts in the latter
directory are usually reserved for system administrator use, and using them
in packages is deprecated.
-->
<p>全ての Unix と同様に Debian は <tt>init</tt> プログラムを実行すること
によってブートアップします。<tt>init</tt> の設定ファイル
(<tt>/etc/inittab</tt>) にはスクリプト <tt>/etc/init.d/rcS</tt> を最初に
実行するように書かれています。このスクリプトはファイルシステムを検査して
マウントし、モジュールをロードして、ネットワークサービスを開始します。ま
た時刻を合わせたり、その他の初期化も行います。それから
<tt>/etc/rc.boot/</tt> にある (ファイル名に '.' が付くものを除いた) 全て
のスクリプトを実行します。ここにあるスクリプトはシステム管理者のために予
約されており、パッケージでそれを使うことは推奨されません。
<!--
<p>After completing the boot process, <tt>init</tt> executes all start
scripts in a directory specified by the default runlevel (this runlevel
is given by the entry for <tt>id</tt> in <tt>/etc/inittab</tt>).
Like most <!-- all? SGK --> System V compatible Unices, Linux has 7 runlevels:
<list>
<item>0 (halt the system),
<item>1 (single-user mode),
<item>2 through 5 (various multi-user modes), and
<item>6 (reboot the system).
</list>
Debian systems come with id=2, which indicates that the default
runlevel will be '2' when the multi-user state is entered, and the
scripts in <tt>/etc/rc2.d/</tt> will be run.
-->
<p>ブートプロセスを終えると <tt>init</tt> はデフォルトのランレベル (この
ランレベルは <tt>/etc/inittab</tt> に書かれた <tt>id</tt> のエントリによっ
て与えられます) によって指定されたディレクトリ中の全ての開始スクリプトを
実行します。多くの System V 互換 Unix と同様に Linux には 7 つのランレベ
ルがあります。
<list>
<item>0 (システムを停止する)
<item>1 (シングルユーザモード)
<item>2 から 5 (様々なマルチユーザモード)
<item>6 (システムの再起動)
</list>
Debian システムは id=2 で始まります。これはマルチユーザ状態に入った時の
デフォルトのランレベルが 2 であり、<tt>/etc/rc2.d/</tt> の中のスクリプト
が実行されることを意味しています。
<!--
<p>In fact, the scripts in any of the directories, <tt>/etc/rcN.d/</tt>
are just symbolic links back to scripts in <tt>/etc/init.d/</tt>. However,
the <em>names</em> of the files in each of the <tt>/etc/rcN.d/</tt>
directories are selected to indicate the <em>way</em> the scripts in
<tt>/etc/init.d/</tt> 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.
-->
<p>実際には、<tt>/etc/rcN.d/</tt> のどのディレクトリのスクリプトも
<tt>/etc/init.d/</tt> の中にあるスクリプトへの単なるシンボリックリンクに
なっています。しかし、ディレクトリ <tt>/etc/rcN.d/</tt> の各々の<em>ファ
イル名</em>は、<tt>/etc/init.d/</tt> 中のスクリプトを走らせる<em>方法
</em>がわかるように選ばれています。具体的に言うと、あるランレベルに入る
前に「K」で始まる全てのスクリプトが実行されます。これによってそのサービ
スは停止されます。次に「S」で始まる全てのスクリプトが実行されます。これ
によってそのサービスは開始されます。「K」や「S」に続く 2 桁の数はスクリ
プトが実行される順番を表しており、数の小さいスクリプトが最初に実行されま
す。
<!--
<p>This approach works because the scripts in <tt>/etc/init.d/</tt> 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.
-->
<p>このやり方はうまく機能します。というのも <tt>/etc/init.d/</tt> の中に
あるスクリプトはすべて「start」か「stop」か「reload」か「restart」か
「force-reload」のどれかを引数にとり、その引数に従って定められた仕事を行
うからです。これらのスクリプトはシステムがブートしてしまった後でも様々な
プロセスを制御するために利用できます。
<!--
<p>For example, with the argument `reload' the command
<example>/etc/init.d/sendmail reload</example>
sends the sendmail daemon a signal to reread its configuration file.
-->
<p>例えば「reload」を引数としたコマンド <tt>/etc/init.d/sendmail
reload</tt> は sendmail デーモンに設定ファイルを再読み込みするようシグナ
ルを送ります。
<!--
<sect id="custombootscripts">It looks as if Debian does not use
<tt>rc.local</tt> to customize the boot process; what facilities
are provided?
-->
<sect id="custombootscripts">Debian はブートプロセスをカスタマイズするの
に <tt>rc.local</tt> を使っていないようですね。どんな手段が使えるのです
か?
<!--
<p>Suppose a system needs to execute script <tt>foo</tt> on start-up,
or on entry to a particular (System V) runlevel. Then the system
administrator should:
<list>
<item>Enter the script <tt>foo</tt> into the directory <tt>/etc/init.d/</tt>.
<item>Run the Debian command <tt>update-rc.d</tt> with appropriate
arguments, to set up links between the (command-line-specified) directories
rc?.d and <tt>/etc/init.d/foo</tt>. Here, '?' is a number from 0 through 6
and corresponds to each of the System V runlevels.
<item>Reboot the system.
</list>
-->
<p>起動時や特定の (System V) ランレベルへの入り口でシステムがスクリプト
<tt>foo</tt> を実行しなければならないとします。その場合システム管理者は
次のようにして下さい。
<list>
<item>スクリプト <tt>foo</tt> をディレクトリ <tt>/etc/init.d/</tt> に
入れる。
<item>Debian コマンド <tt>update-rc.d</tt> を適切な引数で実行する。こ
れにより、引数としてコマンドラインに指定したディレクトリ rc?.d と
<tt>/etc/init.d/foo</tt> の間にリンクが作られます。ここで「?」は 0 か
ら 6 までの数であり、System V のランレベルに対応します。
<item>システムを再起動する。
</list>
<!--
<p>The command <tt>update-rc.d</tt> will set up links between files in
the directories rc?.d and the script in <tt>/etc/init.d/</tt>.
Each link will begin with a 'S' or a 'K', followed by a number, followed
by the name of the script. Scripts beginning with 'S' in
<tt>/etc/rcN.d/</tt> are executed when runlevel <tt>N</tt> is entered.
Scripts beginning with a 'K' are executed when leaving runlevel <tt>N</tt>.
-->
<p>コマンド <tt>update-rc.d</tt> は <tt>/etc/init.d/</tt> の中のスクリプ
トからディレクトリ rc?.d の中のファイルへのリンクを作成します。各々のリ
ンクは「S」か「K」で始まり、その次に数字が続き、最後にスクリプトの名前が
続きます。<tt>/etc/rcN.d/</tt> の中の「S」で始まるスクリプトはランレベル
<tt>N</tt> に入った時に実行されます。「K」で始まるスクリプトはランレベル
<tt>N</tt> を離れた時に実行されます。
<!--
<p>One might, for example, cause the script <tt>foo</tt> to execute at
boot-up, by putting it in <tt>/etc/init.d/</tt> and installing the links with
<tt>update-rc.d foo defaults 19</tt>. The argument 'defaults' refers
to the default runlevels, which are 2 through 5. The argument '19' ensures
that <tt>foo</tt> is called before any scripts containing numbers 20
or larger.
-->
<p>例えば、スクリプト <tt>foo</tt> を <tt>/etc/init.d/</tt> の中に置き、
<tt>update-rc.d foo defaults 19</tt> としてリンクを作成すると、スクリプ
ト foo を起動時に実行させることができます。ここで引数「defaults」はデフォ
ルトのランレベルである 2 から 5 を表しており、引数「19」は
<tt>foo</tt> がファイル名に 20 以上の数を含んでいるスクリプトよりも先に
呼び出されることを表しています。
<!--
<sect id="interconffiles">How does the package management system deal with
packages that contain configuration files for other packages?
-->
<sect id="interconffiles">パッケージ管理システムでは、別のパッケージに関
する設定ファイルを含んでいるようなパッケージをどのようにして取り扱うので
すか?
<!--
<p>Some users wish to create, for example, a new server by installing a
group of Debian packages and a locally generated package consisting of
configuration files. This is not generally a good idea, because <prgn/dpkg/
will not know about those configuration files if they are in a different
package, and may write conflicting configurations when one of the
initial "group" of packages is upgraded.
-->
<p>例えば、ユーザの環境に合わせた設定ファイルを含むパッケージをローカル
に作成しておき、いくつかの Debian パッケージ群とこの設定ファイルを含むパッ
ケージをインストールすることで簡単に新しいサーバを作りたい、という状況を
考えてみます。これは一般的に良い考えではありません。もし設定ファイルが別
のパッケージの中にあっても <prgn/dpkg/ はそれらの設定ファイルについて知
るはずもなく、パッケージ「群」の一つをアップグレードした時に設定ファイル
も更新されて矛盾が生じてしまうからです。
<!--
<p>Instead, create a local package that modifies the configuration files
of the "group" of Debian packages of interest. Then <prgn/dpkg/ and the
rest of the package management system will see that the files have been
modified by the local "sysadmin" and will not try to overwrite them when
those packages are upgraded.
-->
<p>代わりに、関心のある Debian パッケージ「群」の設定ファイルを修正する
ローカルなパッケージを作って下さい。こうすれば、<prgn/dpkg/ などのパッケー
ジ管理システムは、ファイルがローカルな「システム管理者」によって修正され
たかどうかわかるので、パッケージをアップグレードする時に上書きされること
はありません。
<!-- check against dpkg-divert description -->
<!--
<sect id="divert">How do I override a file installed by a package, so that
a different version can be used instead?
-->
<sect id="divert">あるパッケージによってインストールされたファイルを上書
きして、代わりに違うバージョンのものを使うにはどうすればいいのですか?
<!--
<p>Suppose a sysadmin or local user wishes to use a program "login-local"
rather than the program "login" provided by the Debian <package/login/
package.
-->
<p>システム管理者やローカルユーザが、Debian の <package/login/ パッケー
ジに含まれる「login」プログラムではなく「login-local」プログラムを使いた
いとします。
<!--
<p>Do <strong/not/:
<list>
<item>Overwrite <tt>/bin/login</tt> with <tt>login-local</tt>.
</list>
The package management system will not know about this change, and will simply
overwrite your custom <tt>/bin/login</tt> whenever <tt>login</tt> (or any
package that provides <tt>/bin/login</tt>) is installed or updated.
-->
<p>次のようにしてはいけません。
<list>
<item><tt>/bin/login</tt> を <tt>login-local</tt> で上書きする。
</list>
パッケージ管理システムはこの変更について知るはずもなく、<tt>login</tt>
(あるいは <tt>/bin/login</tt> を提供するパッケージ) を新たにインストール
したり更新したりすると、カスタム <tt>/bin/login</tt> は単純に上書きされ
てしまいます。
<!-- XXX dpkg-divert: is this correct ? -->
<!--
<p>Rather, do
<list>
<item>Execute:
<example>dpkg-divert --divert /bin/login.debian /bin/login</example>
in order to cause all future installations of the Debian <package/login/
package to write the file <tt>/bin/login</tt> to <tt>/bin/login.debian</tt>
instead.
<item>Then execute:
<example>cp login-local /bin/login</example>
to move your own locally-built program into place.
</list>
-->
<p>代わりに次のようにして下さい。
<list>
<item><example>dpkg-divert --divert /bin/login.debian /bin/login</example>
を実行する。こうすれば、Debian <tt>login</tt> パッケージを将来イン
ストールすると、<tt>/bin/login</tt> ではなく
<tt>/bin/login.debian</tt> にインストールされます。
<item>次に
<example>cp login-local /bin/login</example>
を実行する。ローカルに構築したプログラムを <tt>/bin/login</tt> へ移動
します。
</list>
<!--
<p>Details are given in the manual page <manref name="dpkg-divert" section="8">.
-->
<p>詳しくは マニュアルページ <manref name="dpkg-divert" section="8"> に
書かれています。
<!--
<sect id="localpackages">How can I have my locally-built package included in
the list of available packages that the package management system knows
about?
-->
<sect id="localpackages">パッケージ管理システムが知っている利用可能パッ
ケージのリストの中に自分で作ったパッケージを含めるにはどうすればいいので
すか?
<!--
<p>You can do this in either of two ways:
<list>
<item>Use <tt>dselect</tt>, and reselect the access method. You will be
asked for a directory where your local packages reside.
<item>Execute the command
<tt>dpkg-scanpackages BIN_DIR OVERRIDE_FILE [PATHPREFIX] > Packages.new</tt>
where:
<list>
<item>BIN-DIR is a directory where Debian archive files (which usually
have an extension of ".deb") are stored.
<item>OVERRIDE_FILE is a file that is edited by the distribution
maintainers and is usually stored on a Debian FTP archive at
<tt>indices/override.main.gz</tt> for the Debian packages in
the "main" distribution. You can ignore this for local packages.
<item>PATHPREFIX is an optional string that can be prepended to the
Packages.new file being produced.
</list>
<item>Once you have built the file <tt>Packages.new</tt>, tell the package
management system about it by using the command
<tt>dpkg --update-avail Packages.new</tt>.
</list>
-->
<p>これには次の 2 つの方法があります。
<list>
<item><tt>dselect</tt> を使い、アクセス手段を再選択する。そのローカル
なパッケージがどのディレクトリにあるか聞かれます。
<item>コマンド
<tt>dpkg-scanpackages BIN_DIR OVERRIDE_FILE [PATHPREFIX] > Packages.new</tt>
を実行する。ここで
<list>
<item>BIN-DIR は Debian アーカイブファイル (普通、拡張子「.deb」を持
つ) があるディレクトリです。
<item>OVERRIDE_FILE はディストリビューションメンテナにより編集される
ファイルで、main ディストリビューションの Debian パッケージのものは
普通 Debian FTP アーカイブの <tt>indices/override.main.gz</tt> に保
管されています。ローカルパッケージの場合これは無視できます。
<item>PATHPREFIX は生成される Package.new ファイルに付加することので
きるオプション文字列です。
</list>
<item>いったんファイル <tt>Packages.new</tt> を作ってしまえば、コマン
ド
<tt>dpkg --update-avail Packages.new</tt>
によってパッケージ管理システムにそれを教えることができます。
</list>
<!--
<sect id="diverse">Some users like mawk, others like gawk; some like vim,
others like elvis; some like trn, others like tin; how does Debian
support diversity?
-->
<sect id="diverse">mawk が好きなユーザもいれば gawk が好きなユーザもいま
す。vim が好きなユーザもいれば elvis が好きなユーザもいます。trn が好き
なユーザもいればtin が好きなユーザもいます。このような多様性を Debian は
どのようにしてサポートしていますか?
<!--
<p>There are several cases where two packages provide two different versions
of a program, both of which provide the same core functionality. Users
might prefer one over another out of habit, or because the user
interface of one package is somehow more pleasing than the interface of
another. Other users on the same system might make a different choice.
-->
<p>二つのパッケージがあるプログラムの異なるバージョンを提供しており、双
方が同じ基本機能を提供しているといういくつかのケースがあります。ユーザが
どちらか一方のパッケージを好むのは、習慣からかもしれませんし、あるパッケー
ジのユーザインタフェースが別のものよりもどういうわけか心地よいという理由
からかもしれません。同じシステムの別のユーザは違う選択をするかもしれませ
ん。
<!--
<p>Debian uses a "virtual" package system to allow system administrators
to choose (or let users choose) their favorite tools when there are two
or more that provide the same basic functionality, yet satisfy package
dependency requirements without specifying a particular package.
-->
<p>Debian では「仮想」パッケージシステムを使うことによって、同じ基本機能
を提供する 2 つ以上のパッケージが存在している時にシステム管理者 (あるい
はユーザ) がお気に入りのツールを選ぶことができます。また、特定のパッケー
ジを指定しなくてもパッケージ依存条件が満たされるようになっています。
<!--
<p>For example, there might exist two different versions of newsreaders on
a system. The news server package might 'recommend' that there exist
<em>some</em> news reader on the system, but the choice of <tt>tin</tt>
or <tt>trn</tt> is left up to the individual user. This is satisfied by
having both the <package/tin/ and <package/trn/ packages provide the
virtual package <package/news-reader/. <em>Which</em> program is
invoked is determined by a link pointing from a file with the virtual
package name <tt>/etc/alternatives/news-reader</tt> to the selected file,
e.g., <tt>/usr/bin/trn</tt>.
-->
<p>例えば、一つのシステムに 2 つの異なるニュースリーダーが存在するとしま
す。ニュースサーバパッケージは、システムに<em>なんらかの</em>ニュースリー
ダーがインストールされていることを「recommend (推薦)」してはいますが、
<tt>tin</tt> か <tt>trn</tt> かという選択は個々のユーザに任せています。
これがうまく機能するのは、<tt>tin</tt> と <tt>trn</tt> が共に仮想パッケー
ジ <tt>news-reader</tt> を提供しているからです。<em>どの</em>プログラム
が実行されるかは、仮想パッケージ名を持つファイル
<tt>/etc/alternatives/news-reader</tt> から選択したファイル、例えば
<tt>/usr/bin/trn</tt> へリンクを張ることにより決定されます。
<!--
<p>A single link is insufficient to support full use of an alternate
program; normally, manual pages, and possibly other supporting files
must be selected as well. The Perl script <tt>update-alternatives</tt>
provides a way of ensuring that all the files associated with a specified
package are selected as a system default.
-->
<p>このような方法を使う場合、リンクが一つだけではプログラムを十分に利用
するのに不十分です。普通、マニュアルページやその他のサポートファイルも適
切に選択されていなければなりません。Perl スクリプト
<tt>update-alternative</tt> を使えば、パッケージに関連する全てのファイル
をシステムデフォルトとして正しく選択することができます。
<!--
<p>For example, to check what executables provide `x-window-manager', run:
<example>update-alternatives --display x-window-manager</example>
If you want to change it, run:
<example>update-alternatives --config x-window-manager</example>
And follow the instructions on the screen (basically, press the number
next to the entry you'd like better).
-->
<p>例えば、どの実行ファイルが「x-window-manager」を提供するのかをチェッ
クするには
<example>update-alternatives --display x-window-manager</example>
を走らせます。それを変更したいのなら
<example>update-alternatives --config x-window-manager</example>
を走らせ、画面の指示に従います (基本的には選択したいエントリの次の番号を
入力します)。
<!--
<p>If a package doesn't register itself as a window manager for some reason
(file a bug if it's in error), or if you use a window manager from /usr/local
directory, the selections on screen won't contain your preferred entry.
You can update the link through command line options, like this:
<example>update-alternatives --install /usr/bin/x-window-manager \
x-window-manager /usr/local/bin/wmaker-cvs 50</example>
-->
<p>何らかの理由でパッケージが自分自身をウィンドウマネージャとして登録し
ない場合 (エラーになるならバグとして提出してください)、あるいは
/usr/local ディレクトリにあるウィンドウマネージャを使いたい場合は、選択
したいエントリが画面の選択肢に現れないでしょう。そんなときは例えば以下の
ようにコマンドラインオプションでリンクを更新できます。
<example>update-alternatives --install /usr/bin/x-window-manager \
x-window-manager /usr/local/bin/wmaker-cvs 50</example>
<!--
<p>The first argument to `--install' option is the symlink that points to
/etc/alternatives/NAME, where NAME is the second argument. The third argument
is the program to which /etc/alternatives/NAME should point to, and the
fourth argument is the priority (larger value means the alternative will more
probably get picked automatically).
-->
<p>「--install」オプションの第一引数は /etc/alternatives/NAME へのシンボ
リックリンクです。ここで NAME が次の引数になります。第三引数は
/etc/alternatives/NAME が指すべきプログラムです。第四引数は優先度で、大
きな値を指定すると自動的に選択される可能性が大きくなります。
<!--
<p>To remove an alternative you added, simply run:
<example>update-alternatives --remove x-window-manager /usr/local/bin/wmaker-cvs</example>
-->
<p>別候補を削除するには単に
<example>update-alternatives --remove x-window-manager /usr/local/bin/wmaker-cvs</example>
を実行してください。