[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
packaging manual の和訳
Debian packaging manual の訳をお手伝いしている早瀬です。
Debian のパッケージのメンテナーになることを目指して、
パッケージングの勉強を兼ねています。
この度、第６章 Package maintainer scripts and installation procedure を
訳してみました。
しかしながら、私にはパッケージ構築の経験が乏しく、maintainer script を
扱ったこともありません。ですので、パッケージのメンテナーの方々に、
この文章を査読して頂きたいと思っています。よろしくお願いします。
なお、このメールに添付しましたファイルは、HTML を Netscape で読んで、
テキスト形式でセーブしたものなので、斜体文字や、インデントがうまく
いっていないようです。
http://www.iis.u-tokyo.ac.jp/~hayase/ch-maintainerscripts.html
に同じ物を置いておきました。
----------------------------------------------------------------
早瀬 茂規 (hayase@xxxxxxxxxxxxxxxxxxxxxxxx)
Debian pacakging manual - 第 6 章
パッケージ管理スクリプトと インストールの手順
------------------------------------------------------------------------
PATH（環境変数）、exit status、unpack は訳し方がわからなかったので、 そのま
まにしてあります。
6.1 パッケージ管理スクリプトの手引き
It is possible supply scripts as part of a package which dpkg will run for
you when your package is installed, upgraded or removed.
パッケージをインストール、アップグレード、削除する際に、dpkg が 走
らせるスクリプトをパッケージの一部として供給することが可能です。
These scripts should be the files preinst, postinst, prerm and postrm in the
control area of the package. They must be proper exectuable files; if they
are scripts (which is recommended) they must start with the usual #!
convention. They should be readable and executable to anyone, and not
world-writeable.
これらのスクリプトはパッケージの制御エリア内にある、preinst、
postinst、prerm、postrm という ファイルです。これらは適正な実行可
能ファイルでなくてはなりません。 もし、これらがスクリプトで（スク
リプトであることを推奨します。）あるならば、 通常行われているよう
に #! で始めなくてはなりません。 これらのスクリプトは誰でも読むこ
とが可能で、実行可能である必要があり、 誰にでも書き込み可能であっ
てはいけません。
dpkg looks at the exit status from these scripts. It is important that they
exit with a non-zero status if there is an error, so that dpkg can stop its
processing. For shell scripts this means that you almost always need to use
set -e (this is usually true when writing shell scripts, in fact). It is
also important, of course, that they don't exit with a non-zero status if
everything went well.
dpkg はこれらのスクリプトからの exit status を見ます。 dpkg が手続
きを止められるように、エラーがあった場合には スクリプトがゼロでな
い status で終了することが重要です。シェルスクリプトでは ほとんど
常に set -e を使う必要があるということを意味します （実際には、通
常シェルスクリプトを書く場合は一般に、このようにします）。 もちろ
ん、全てがうまくいった場合に、ゼロでない status で終了しないことも
重要です。
It is necessary for the error recovery procedures that the scripts be
idempotent: ie, invoking the same script several times in the same situation
should do no harm. If the first call failed, or aborted half way through for
some reason, the second call should merely do the things that were left
undone the first time, if any, and exit with a success status.
エラー回復手続きをできるようにするため、スクリプトには等能力がある
必要が あります。どういうことかと言うと、同じ状況にあるときに、同
じスクリプトを 何度か起動しても無害でなければならないということで
す。もし、一回目の呼び出しが 失敗した、または何らかの理由によって
途中で中止した場合、二回目の呼び出しでは、 一回目で残されたものが
あれば、それを単に実行し、成功 status で 終了しなくてはいけませ
ん。
When a package is upgraded a combination of the scripts from the old and new
packages is called in amongst the other steps of the upgrade procedure. If
your scripts are going to be at all complicated you need to be aware of
this, and may need to check the arguments to your scripts.
パッケージがアップグレードされる時には、アップグレード手続きの他の
段階の間に 古いパッケージと新しいパッケージのスクリプトが、組み合
わせて呼び出されます。 もし、あなたのスクリプトがとても複雑になっ
ていく場合には、このことに注意し、 スクリプトの引数のチェックが必
要になるでしょう。
Broadly speaking the preinst is called before (a particular version of) a
package is installed, and the postinst afterwards; the prerm before (a
version of) a package is removed and the postrm afterwards.
大まかに言えば、preinst は（ある特定のバージョンの）パッケージが
インストールされる前に、postinst はインストールされた後に 呼び出さ
れます。prerm は（あるバージョンの）パッケージが削除される 前に、
postrm は削除された後に呼び出されます。
Programs called from maintainer scripts should not normally have a path
prepended to them. Before installation is started dpkg checks to see if the
programs ldconfig, start-stop-daemon, install-info, and update-rc.d can be
found via the PATH environment variable. Those programs, and any other
program that one would expect to on the PATH, should thus be invoked without
an absolute pathname. Maintainer scripts should also not reset the PATH,
though they might choose to modify it by pre- or appending package-specific
directories. These considerations really apply to all shell scripts.
管理スクリプトから呼ばれるプログラムは、通常、そのスクリプトにおい
てプログラムの 前に path をつけて呼び出してはいけません。インスト
ールが始まる前に、 dpkg は ldconfig、start-stop-daemon、
install-info、update-rc.d が PATH 環境変数から 発見できるかどうか
をチェックします。ですから、これらのプログラムや、 PATH にあること
が期待されるプログラムについては、 絶対パス名をつけること無しに呼
び出すことができます。管理スクリプトは PATH をリセットしてはいけま
せんが、PATH の前か後に、 パッケージに対して特別なディレクトリを付
け加えるという方法を採るのは かまいません。このような考慮は、実際
には、全てのシェルスクリプトに対して 当てはまるものです。
------------------------------------------------------------------------
6.2 管理スクリプトの呼び出され方の一覧
* new-preinst install
* new-preinst install old-version
* new-preinst upgrade old-version
* old-preinst abort-upgrade new-version
* postinst configure most-recently-configured-version
* old-postinst abort-upgrade new version
* conflictor's-postinst abort-remove in-favour package new-version
* deconfigured's-postinst abort-deconfigure in-favour
failed-install-package version removing conflicting-package version
* prerm remove
* old-prerm upgrade new-version
* new-prerm failed-upgrade old-version
* conflictor's-prerm remove in-favour package new-version
* deconfigured's-prerm deconfigure in-favour package-being-installed
version removing conflicting-package version
* postrm remove
* postrm purge
* old-postrm upgrade new-version
* new-postrm failed-upgrade old-version
* new-postrm abort-install
* new-postrm abort-install old-version
* new-postrm abort-upgrade old-version
* disappearer's-postrm disappear overwriter new-version
------------------------------------------------------------------------
6.3 インストールやアップグレードでの unpack の段階の詳細
The procedure on installation/upgrade/overwrite/disappear (ie, when running
dpkg --unpack, or the unpack stage of dpkg --install) is as follows. In each
case if an error occurs the actions in are general run backwards - this
means that the maintainer scripts are run with different arguments in
reverse order. These are the `error unwind' calls listed below.
インストール／アップグレード／上書き／消失（すなわち、dpkg
--unpack が走っているとき、または dpkg --install の unpack の段階
のとき） の手続きは以下の通りになります。どのような場合において
も、もしエラーが起これば そこでの動作は、一般に逆方向へ走らされま
す。これは、管理スクリプトが異なる引数で 逆順に走らされるというこ
とです。これらは「エラー回復」呼び出しとして 以下に挙げられていま
す。
1.
1. If a version the package is already installed, call
もし対象となるパッケージのあるバージョンが既にインストールされてい
る場合、 次の呼び出しをします。
old-prerm upgrade new-version
2. If this gives an error (ie, a non-zero exit status), dpkg will
attempt instead:
もし、これがエラーとなったら（つまり、ゼロでない exit status であ
ったら）、 はかわりに次の呼び出しをします。
new-prerm failed-upgrade old-version
Error unwind, for both the above cases:
上の両方の場合におけるエラー回復：
old-postinst abort-upgrade new-version
2. If a `conflicting' package is being removed at the same time:
「衝突する」パッケージが同時に削除される場合
1. If any packages depended on that conflicting package and
--auto-deconfigure is specified, call, for each such package:
もし、その衝突するパッケージに依存するパッケージがあり、
--auto-deconfigure が指定されているならば、 そのようなそれぞれのパ
ッケージについて、次の呼び出しを行います。
deconfigured's-prerm deconfigure \
in-favour package-being-installed version \
removing conflicting-package version
Error unwind:
エラー回復：
deconfigured's-postinst abort-deconfigure \
in-favour package-being-installed-but-failed version \
removing conflicting-package version
The deconfigured packages are marked as requiring configuration,
so that if --install is used they will be configured again if
possible.
もし、--install が使われたら、再設定可能な場合に再設定が行われる
ようにするため、設定破棄されたパッケージには設定を要求するマークが
付けられます。
2. To prepare for removal of the conflicting package, call:
衝突しているパッケージを削除するための準備として、次の呼び出しが行
われます。
conflictor's-prerm remove in-favour package new-version
Error unwind:
エラー回復：
conflictor's-postinst abort-remove \
in-favour package new-version
3.
1. If the package is being upgraded, call:
パッケージがアップグレードされる場合には、次の呼び出しが行われま
す。
new-preinst upgrade old-version
2. Otherwise, if the package had some configuration files from a
previous version installed (ie, it is in the `configuration files
only' state):
そうではない場合、もし、そのパッケージの以前のバージョンからの設定
ファイルが あった（すなわち「設定ファイルのみ」の状態にあった）な
らば、 次の呼び出しが行われます。
new-preinst install old-version
3. Otherwise (ie, the package was completely purged):
そうでもない（つまり、そのパッケージが完全に排除されていた）場合、
次の呼び出しが行われます。
new-preinst install
Error unwind versions, respectively:
それぞれに対するエラー回復：
new-postrm abort-upgrade old-version
new-postrm abort-install old-version
new-postrm abort-install
4. The new package's files are unpacked, overwriting any that may be on
the system already, for example any from the old version of the same
package or from another package (backups of the old files are left
around, and if anything goes wrong dpkg will attempt to put them back
as part of the error unwind).
新しいパッケージのファイルは unpack され、システムに既にあるファイル、
例えば同じパッケージの古いバージョンからのファイルや、 他のパッケージか
らのファイルに上書きされます。 （古いファイルのバックアップが残され、も
し何か問題が起これば dpkg が エラー回復の一部としてそれらを元に戻そうと
します。）
It is an error for a package to contains files which are on the system
in another package, unless Replaces is used (see Replaces - overwriting
files and replacing packages, section 8.5). Currently the
--force-overwrite flag is enabled, downgrading it to a warning, but
this may not always be the case.
Replaces が使われていない場合に、他のパッケージのファイルが システム上
に存在すれば、パッケージに対してエラーとなります。 （8.5 節 Replaces -
overwriting files and replacing packages を見てください。） 現在のとこ
ろ --force-overwrite フラグが有効にされており、このエラーは 警告に格下
げされています。しかし、常にこのようであってはいけません。
It is a more serious error for a package to contain a plain file or
other kind of nondirectory where another package has a directory
(again, unless Replaces is used). This error can be overridden if
desired using --force-overwrite-dir, but this is not advisable.
パッケージにとってもっと深刻なエラーとなるのが、他のパッケージからのデ
ィレクトリーが ある場所に、簡単なファイルや、他のディレクトリでないファ
イルがある場合です。 （ここでも、Replaces が使われていない場合において
です。） もし望むなら、--force-overwrite-dir を使うことでこのエラーを無
効に することができます。しかしこれは勧められません。
Packages which overwrite each other's files produce behaviour which
though deterministic is hard for the system administrator to
understand. It can easily lead to `missing' programs if, for example, a
package is installed which overwrites a file from another package, and
is then removed again.[19]
お互いのファイルに上書きするパッケージは、決定論的に決まるのではあるけ
れども、 システム管理者には理解しがたい振る舞いをします。この状態では、
簡単にプログラムを 「見失う」事態が起こり得ます。例えば、他のパッケージ
からのファイルに上書きする ようなパッケージをインストールして、それか
ら、そのパッケージを削除することで 起こります。[19]
A directory will never be replaced by a symbolic links to a directory
or vice versa; instead, the existing state (symlink or not) will be
left alone and dpkg will follow the symlink if there is one.
ディレクトリは、決してディレクトリへのシッンボリックリンクに置き換わっ
てしまう ことがありませんし、その逆もありません。そのかわりに、現在ある
状態 （シンボリックリンクであるのか、そうではないのか）は変化させず、
もしシンボリックリンクがあれば dpkg はそれを追いかけます。
5.
1. If the package is being upgraded, call
もし、パッケージがアップグレードされている最中なら、次の呼び出しを
行います。
old-postrm upgrade new-version
2. If this fails, dpkg will attempt:
もしこれに失敗したら、dpkg は次の呼び出しを試みます。
new-postrm failed-upgrade old-version
Error unwind, for both cases:
上の両方の場合におけるエラー回復：
old-preinst abort-upgrade new-version
This is the point of no return - if dpkg gets this far, it won't back
off past this point if an error occurs. This will leave the package in
a fairly bad state, which will require a successful reinstallation to
clear up, but it's when dpkg starts doing things that are irreversible.
ここが戻れなくなるポイントです。dpkg がさらに先に進むと、 エ
ラーがあった場合には このポイントより前には戻りません。この場
合、パッケージが非常に悪い状態で 残ります。これをきれいにする
ためには、再インストールを成功させる必要があります。 しかしこ
のとき、dpkg は戻ることのできなかったことから作業を 始めるこ
とになります。
6. Any files which were in the old version of the package but not in the
new are removed.
古いバージョンのパッケージにはあって、新しいものには無いファイルを削除
します。
7. The new file list replaces the old.
ファイルリストを古いものから新しいものに置き換えます。
8. The new maintainer scripts replace the old.
管理スクリプトを古いものから新しいものに置き換えます。
9. Any packages all of whose files have been overwritten during the
installation, and which aren't required for dependencies, are
considered to have been removed. For each such package,
あるパッケージに属するファイルが、インストールの間に全て上書
きされ、 依存の要求も無いような場合、そのパッケージは削除され
たとみなされます。 そのようなパッケージそれぞれに対して、
1. dpkg calls:
dpkg は次の呼び出しを行います。
disappearer's-postrm disappear \
overwriter overwriter-version
2. The package's maintainer scripts are removed.
パッケージ管理スクリプトが削除されます。
3. It is noted in the status database as being in a sane state,
namely not installed (any conffiles it may have are ignored,
rather than being removed by dpkg). Note that disappearing
packages do not have their prerm called, because dpkg doesn't know
in advance that the package is going to vanish.
パッケージ状態のデータベースには、正常な状態、つまりイン
ストールされていないもの として記録されます。（そのパッ
ケージが持っていた設定ファイルがあれば、 それは dpkg に
よって削除されるのではなく、無視されます。） dpkg は前も
って、そのパッケージが消失されそうなのか知らないので、
消失されるパッケージの prerm は呼び出されないということ
に 注意してください。
10. Any files in the package we're unpacking that are also listed in the
file lists of other packages are removed from those lists. (This will
lobotomise the file list of the `conflicting' package if there is one.)
unpack しようとしているパッケージの中にあって、他のパッケージ
のファイルリストにも 記されている全てのファイルは、これらのリ
ストから削除されます。（これにより、 もし「衝突する」パッケー
ジがあれば、その衝突するパッケージのファイルリストが 修正され
ます。） ［lobotomy: 過去に行われていた、心理的な混乱を直すた
めに脳の前部に施す手術の ことをロボトミーと言うらしいです。］
11. The backup files made during installation, above, are deleted.
今までのインストール作業の中で作成されていたバックアップファイルを消去
します。
12. The new package's status is now sane, and recorded as `unpacked'. Here
is another point of no return - if the conflicting package's removal
fails we do not unwind the rest of the installation; the conflicting
package is left in a half-removed limbo.
新しいパッケージの状態は、今では正常になっていますので、
「unpacked」として 記録されます。ここがもう一つの戻れなくなる
ポイントです。もし衝突するパッケージの 削除に失敗すると、これ
より前に残っているインストール作業は回復されません。 衝突する
パッケージは半分削除されて、忘れ去られます。
13. If there was a conflicting package we go and do the removal actions
(described below), starting with the removal of the conflicting
package's files (any that are also in the package being installed have
already been removed from the conflicting package's file list, and so
do not get removed now).
もし衝突するパッケージがあれば、（これから示される）削除作業
へ移り、実行します。 削除作業は衝突するパッケージのファイルを
削除することから始まります。 （インストールされたパッケージの
中にもあるファイルは、すでに、衝突するパッケージの ファイルリ
ストから削除されているので、今、削除されてしまうことはありま
せん。）
------------------------------------------------------------------------
6.4 設定の詳細
When we configure a package (this happens with dpkg --install, or with
--configure), we first update the conffiles and then call:
パッケージを設定する（この状況は dpkg --install、 --configure によ
り生じます）とき、まず設定ファイルを更新し、 それから次の呼び出し
が行われます。
postinst configure most-recently-configured-version
No attempt is made to unwind after errors during configuration.
設定中にエラーが起こった後、回復は行われません。
If there is no most recently configured version dpkg will pass a null
argument; older versions of dpkg may pass <unknown> (including the angle
brackets) in this case. Even older ones do not pass a second argument at
all, under any circumstances.
もし設定されたバージョン（上の呼び出しの
most-recently-configured-version） が存在しなければ、dpkg は引数に
対して何も渡しません。 この場合に、古いバージョンの dpkg は
<unknown> （角括弧も含めて）を渡します。さらに古いバージョンの
dpkg では、 どのような状況においても二番目の引数には何も渡しませ
ん。
------------------------------------------------------------------------
6.5 削除と設定の排除の詳細
1. prerm remove
2. The package's files are removed (except conffiles).
パッケージのファイルを（設定ファイルを除いて）削除します。
3. postrm remove
4. All the maintainer scripts except the postrm are removed.
postrm以外の管理スクリプトを全て削除します。
If we aren't purging the package we stop here. Note that packages which
have no postrm and no conffiles are automatically purged when removed,
as there is no difference except for the dpkg status.
もしパッケージを排除（purge）しているのでなければ、ここで止ま
ります。 パッケージに postrm も設定ファイルもないのであれば、
削除（remove）のときには dpkg の状態以外に違いが無いので、 自
動的に排除（purge）されることに注意してください。
5. The conffiles and any backup files (~-files, #*# files, %-files,
.dpkg-{old,new,tmp}, etc.) are removed.
設定ファイルと全てのバックアップファイル（~ ファイル、 #*# ファイル、%
ファイル、 .dpkg-{old,new,tmp} など）が削除されます。
6. postrm purge
7. The package's file list is removed.
パッケージのファイルリストが削除されます。
No attempt is made to unwind after errors during removal.
削除中にエラーが起こった後、回復は行われません。
------------------------------------------------------------------------
Debian pacakging manual - Copyright *Iゥ1996 Ian Jackson.*B
目次; 摘要; 次章; 前章.
version 2.1.2.2 (dpkg 1.4.0.17), 16 May 1997
Ian Jackson ijackson@xxxxxxxxxxxxxx
校正: David A. Morris bweaver@debian.org