<!--
The FreeBSD Documentation Project
The FreeBSD Japanese Documentation Project
Original revision: 1.61
$FreeBSD: doc/ja_JP.eucJP/books/handbook/cutting-edge/chapter.sgml,v 1.24 2001/04/08 15:33:40 hrs Exp $
-->
<chapter id="cutting-edge">
<title>開発の最前線</title>
<para><emphasis>改訂: &a.jim;, 2000 年 3 月.</emphasis></para>
<para><emphasis>原作: &a.jkh;, &a.phk;, &a.jdp;, &a.nik;,
およびたくさんのフィードバック.</emphasis></para>
<sect1>
<title>この章では</title>
<para>あるリリースから次のリリースまでの期間にも,
FreeBSD の開発は休みなく続けられています.
この開発の最前線に興味を持っている人のために,
手元のシステムを最新の開発ツリーに同期させておくための,
とても使いやすい仕掛けが何種類も用意されています.
注意: 開発の最前線は,
誰もが扱えるという性質のものではありません!
もしもあなたが, 開発途中のシステムを追いかけようか,
それともリリースバージョンのどれかを使い続けようかと迷っているのなら,
きっとこの章が参考になるでしょう.</para>
</sect1>
<sect1 id="current-stable">
<title>-CURRENT vs. -STABLE</title>
<para>FreeBSD には二つの開発ブランチがあります.
それは -CURRENT と -STABLE です.
この章ではそれぞれについて簡単に説明し,
どのようにしてあなたのシステムを対応するツリーに対して,
どうやって常に最新の状態に保つかについて扱います.
まずは -CURRENT, 次に -STABLE について説明します.</para>
<para><emphasis>訳: &a.hanai;, 1996 年 11 月 6 日.</emphasis></para>
<sect2 id="current">
<title>最新の FreeBSDを 追いかける</title>
<para>これを読む前に,
心にとめておいて欲しいことがあります.
-CURRENT とは FreeBSD の開発の<quote>最前線</quote>だということです.
もし FreeBSD を使い始めたばかりなら,
これを運用することについて十分検討を重ねた方が良いでしょう.</para>
<sect3>
<title>FreeBSD-current ってなに?</title>
<para>FreeBSD-CURRENT とは文字通り,
日々変更されている
FreeBSD のソースのスナップショット以外の何ものでもありません.
中には現在開発途上のソフトウェア,
実験的な変更, あるいは過渡的な機能などが含まれています.
また, この中に入っている機能がすべて,
次の公式リリースに入るとは限りません.
FreeBSD-CURRENT をソースからほぼ毎日コンパイルしている人は
たくさんいますが,
時期によってはコンパイルさえできない状態になっていることもあります.
一般的に, これらの問題は可能な限り迅速に解決されますが,
FreeBSD-CURRENT のソースが不幸をもたらすか,
それとも非常に素晴らしい機能をもたらすかというのは文字通り,
ある与えられた 24
時間の間の,
どの部分であなたがソースを手に入れたかによる場合もあるのです.</para>
</sect3>
<sect3>
<title>誰が FreeBSD-current を必要としてるの?</title>
<para>FreeBSD-CURRENT は,
主に次の三つの重要なグループを対象としています.</para>
<orderedlist>
<listitem>
<para>ソースツリーのある部分に関して活発に作業している
FreeBSD グループのメンバ.
彼らにとっては<quote>最新のもの</quote>にしておくのが
絶対に必要なことなのです.</para>
</listitem>
<listitem>
<para>活発にテストしている FreeBSD グループのメンバ.
彼らは, FreeBSD-CURRENT
が<quote>健全である</quote>ことを可能な限り確認するために,
種々の問題と戦う時間を惜しまない人々です.
彼らはまた, 様々な変更に関する提案や
FreeBSD の大まかな方向付けを行ないたいと思っている
人々でもあります.</para>
</listitem>
<listitem>
<para>単に, 様々な事に目を向け, 参考のために
(たとえば動かすためではなく<emphasis>読むため</emphasis>に)
最新のソースを使いたいと思っている FreeBSD
(または他の) グループのまわりにいるメンバ.
これらの人々はまた,
時々コメントやコードを寄稿してくれます.</para>
</listitem>
</orderedlist>
</sect3>
<sect3>
<title>FreeBSD-CURRENT
に期待しては<emphasis>いけない</emphasis>ことは?</title>
<orderedlist>
<listitem>
<para>なにか新しくカッコイイモノがあると聞き,
自分の周囲では一番にそれを持ちたいがために,
リリース前のコードの断片を追いかけること.</para>
</listitem>
<listitem>
<para>バグを修正するための素早い方法.</para>
</listitem>
<listitem>
<para>わたしたちが<quote>公式にサポートする</quote>こと.
わたしたちは 3 つの<quote>公式な</quote>
FreeBSD-CURRENT のグループの一つに,
実際に属する人々を助けるのにベストを尽くしますが,
技術的なサポートを行なうには, 単に「時間が足りない」のです.
これはわたしたちが外の人を助けるの好まない,
ケチで意地悪い人間だということではなく
(もしそうなら FreeBSD なんかやっていません),
文字通りわたしたちは一日に 400 ものメッセージに答え,
<emphasis>かつ</emphasis> FreeBSD
の作業をすることなど出来ない!
ということなのです.
もし, たくさんの質問に答えるか,
それとも FreeBSD を良くする作業を続けるか,
という選択が与えられた場合,
あなた方のほとんどは後者を支持するとわたしは確信しています.</para>
</listitem>
</orderedlist>
</sect3>
<sect3>
<title>FreeBSD-CURRENT を使う</title>
<orderedlist>
<listitem>
<para>&a.current;
と
&a.cvsall;
に加わってください.
これは単に良い考えであるというだけでなく,
<emphasis>必須の</emphasis>ことなのです.
もし
<emphasis>FreeBSD-current</emphasis>
メーリングリストに入っていなければ,
さまざまな人がシステムの現在の状態について
述べているコメントを見ることは決してありませんし,
従って他の人が既に見つけて解決している
多くの問題に戸惑ってあきらめてしまうでしょう.
さらに言うと, システムを正常に保つための
重要な情報を見逃してしまう可能性もあります.</para>
<para>&a.cvsall; メーリングリストでは,
それぞれの変更についての
commit ログを見ることができます.
また, それに関して起こり得る副作用の情報を得ることができますので,
参加する価値のあるメーリングリストです.</para>
<para>これらのメーリングリストに入るには,
&a.majordomo; へ</para>
<programlisting>subscribe freebsd-current
subscribe cvs-all</programlisting>
<para>と書いたメールを送ってください.
オプションとして本文に
<literal>help</literal>
と書けば, Majordomo からあなたへ,
わたしたちがサポートする様々なメーリングリストに参加
/脱退する方法に関する, 詳しいヘルプが送られます.</para>
</listitem>
<listitem>
<para><hostid role="fqdn">ftp.FreeBSD.org</hostid>
からのソースの入手.
以下の 3 つの方法で行なうことができます.</para>
<orderedlist>
<listitem>
<para><link linkend="cvsup">cvsup</link> を
<ulink url="ftp://ftp.FreeBSD.org/pub/FreeBSD/FreeBSD-current/src/share/examples/cvsup/standard-supfile">この supfile</ulink>
を用いて使用する.
これは 2 番目に推薦される方法です.
なぜなら, cvsup によって一度全体を入手し,
後は変更されたところだけを入手することができるからです.
たくさんの人が自動的にソースを最新のものに保つために
cvsup を cron から起動しています.
これを行なうための非常に簡単な方法は, 単に</para>
<blockquote><screen>&prompt.root; <userinput>pkg_add -f \
ftp://ftp.FreeBSD.org/pub/FreeBSD/development/CVSup/cvsupit.tgz</userinput></screen>
</blockquote>
<para>とタイプすることです.</para>
</listitem>
<listitem>
<para><command>ftp</command> を使う.
FreeBSD-current のソースツリーは常に
<ulink url="ftp://ftp.FreeBSD.org/pub/FreeBSD/FreeBSD-current/">
ftp://ftp.FreeBSD.org/pub/FreeBSD/FreeBSD-current/</ulink>
で<quote>公開</quote>されています.
わたしたちはまた, 全体を compress/tar して入手できる
<command>wu-ftpd</command> を使っています.
たとえば,</para>
<screen>usr.bin/lex</screen>
<para>があったとすると,</para>
<screen><prompt>ftp></prompt> <userinput>cd usr.bin</userinput>
<prompt>ftp></prompt> <userinput>get lex.tar</userinput></screen>
<para>とすることにより, ディレクトリ全体(この場合,
usr.bin/lex以下全体) を tar
ファイルとして入手することができます.</para>
</listitem>
<listitem>
<para><application><link linkend="ctm">CTM</link></application>を用いる.
(接続料が高額だったり, e-mail でのアクセスしかできないような)
あまり良質でない TCP/IP 接続の場合には, <application>CTM</application>
を利用すると良いでしょう. ただし,
これには多くの手間がかかりますし,
壊れたファイルを受けとってしまう可能性もあります.
そのため, 最近ではあまり使われなくなっており,
長い間使用できなくなってしまう事態が発生する可能性があります
(訳注: 保守する人が少ないためです).
9600bps 以上の速度で接続しているなら,
<application><link linkend="cvsup">CVSup</link></application>
を利用されることを推奨します.
</para>
</listitem>
</orderedlist>
</listitem>
<listitem>
<para>もし, ソースを眺めるだけでなく,
走らせるために入手しているのであれば,
一部だけ選ぶのではなく, current
の<emphasis>全体</emphasis>を手に入れてください.
なぜなら, ソースのさまざまな部分が他の部分の更新に依存しており,
一部のみをコンパイルしようとすると,
ほぼ間違いなくトラブルを起こすからです.</para>
<para>current をコンパイルする前に
<filename>/usr/src</filename> にある Makefile
を良く読んでください.
アップグレードの処理の一部として,
少なくとも一回は最初に
<link linkend="makeworld">make world</link>
を行なうべきでしょう.
&a.current; を読めば,
次のリリースへ向けて時々必要になる他のブートストラップの方法に関して,
常に最新情報を得ることが出来ます.</para>
</listitem>
<listitem>
<para>アクティブになって下さい!
もし FreeBSD-CURRENT
を走らせているなら, わたしたちはそれに関するコメント,
特に拡張やバグ潰しに関する提案, を欲しています.
コードを伴う提案はもっとも歓迎されるものです!</para>
</listitem>
</orderedlist>
</sect3>
</sect2>
<sect2 id="stable">
<title>FreeBSD の安定状態の持続</title>
<para>あなたが FreeBSD をプロダクション環境下で使っていて
-CURRENT 系列からの修正の最新版を得ていることを確実にしたいなら
-STABLE を使っていた方がいいでしょう. これは新しいリリースが
まとめられた時 -RELEASE がこれから分岐するツリーです.
たとえば, あなたが 3.4-RELEASE のコピーを持っていたとして,
それは単に CD-ROM にまとめられた -STABLE 系列の
<quote>snapshot</quote> に過ぎません. -RELEASE 以降に
-STABLE にマージされた差分を入手するには -STABLE 系列を
<quote>追跡</quote>する必要があります.</para>
<para><emphasis>訳: &a.jp.iwasaki;.</emphasis></para>
<sect3>
<title>FreeBSD-STABLE ってなに?</title>
<para>FreeBSD-STABLE は,
次の本流のリリースを目指した新機能をあまり採り入れない,
保守的な変更のための開発の支流です.
実験的, もしくはテスト未完の変更はこの支流には取り入れられません
(<link linkend="current">最新の FreeBSD を追いかける</link>参照).</para>
</sect3>
<sect3>
<title>誰が FreeBSD-STABLE を必要としているの?</title>
<para>もしあなたが仕事で使用しているとか, なによりも FreeBSD
システムの安定性を最重要視するなら,
<emphasis>stable</emphasis> を追いかけることを考えるべきでしょう.
<emphasis>stable</emphasis>
の支流は前のリリースに関して効果的にバグフィックスされた流れであるため,
最新のリリース
(<ulink url="ftp://ftp.FreeBSD.org/pub/FreeBSD/i386/&rel.current;-RELEASE/">
&rel.current;-RELEASE</ulink> 執筆時点)
をインストールしているのであれば, 特にそうです.</para>
<warning>
<para><emphasis>stable</emphasis>
ツリーが常に完全に互換性があり安定するように努力していますが,
たまに間違いがあることに注意してください
(結局, 内容が吟味されずに素早く送られた変更を含むソースがまだあるのです).
また, <emphasis>current</emphasis> を
<emphasis>stable</emphasis>
へ移行する前に完璧なテストフィックスに最善を尽くしますが,
わたしたちのテストはすべてのケースを十分に網羅しているとは限りません.
もし何か <emphasis>stable</emphasis> で不具合があるようでしたら,
わたしたちに<emphasis>すぐに</emphasis>教えてください
(次の節参照).</para>
</warning>
</sect3>
<sect3>
<title>FreeBSD-STABLE を使う</title>
<orderedlist>
<listitem>
<para>&a.stable; へ加わってください.
このメーリングリストでは,
<emphasis>stable</emphasis> の構築に関連する事柄や,
その他の注意すべき点 に関する情報が流れています.
また開発者は議論の余地がある修正や変更を考えている場合に,
このメーリングリストで公表し,
提案された変更に関して問題が生じるかどうかを返答する機会をユーザに与えます.</para>
<para>また, &a.cvsall; メーリングリストでは,
それぞれの変更がなされると,
起こりうる副作用に関するすべての適切な情報と一緒に
commit log を読むことができます. subscribe
しておきたいもう一つのメーリングリストです. </para>
<para>メーリングリストに参加するには,
&a.majordomo;
へメッセージの本文に次のように書いたメールを送ってください:</para>
<programlisting>subscribe freebsd-stable
subscribe cvs-all</programlisting>
<para>オプションとして本文に `help' と書けば,
Majordomo はわたしたちがサポートするさまざまなメーリングリストに参加 /
脱退する方法に関する詳しいヘルプを送付します.</para>
</listitem>
<listitem>
<para>もし, あなたが新しいシステムをインストールしようとしていて
それを可能な限り安定なものにしておきたいなら,
最新のブランチの snapshot を
<ulink url="ftp://releng4.freebsd.org/pub/FreeBSD">
ftp://releng4.freebsd.org/pub/FreeBSD</ulink>
から取得し,
これを一般のリリースのものと同様にインストールしてください.</para>
<para>もし, 既に FreeBSD の以前のリリースが動いている場合で,
これをソースからアップグレードしようとするならば,
<hostid role="fqdn">ftp.FreeBSD.org</hostid> より簡単に
これを行う事が出来ます. これには次の 3 つの方法があります.
</para>
<orderedlist>
<listitem>
<para><application><link linkend="ctm">CTM</link></application>
機能を使用する. 転送レートが安定している TCP/IP
接続でない場合は, この方法が適しています.</para>
</listitem>
<listitem>
<para><link linkend="cvsup">cvsup</link> を
<ulink url="ftp://ftp.FreeBSD.org/pub/FreeBSD/FreeBSD-current/src/share/examples/cvsup/stable-supfile">この supfile</ulink>
を用いて使用する.
一度コレクション全体を入手してしまえば,
前回からの変更部分だけですむので, 2
番目に推奨される方法です.
多くの人が cron から cvsup を実行し,
自動的にソースコードを最新の状態に保っています.
これを簡単に扱うには次のようにタイプしてください.</para>
<blockquote>
<screen>&prompt.root; <userinput>pkg_add -f \
ftp://ftp.FreeBSD.org/pub/FreeBSD/development/CVSup/cvsupit.tgz</userinput></screen>
</blockquote>
</listitem>
<listitem>
<para><command>ftp</command> を使用する. FreeBSD-STABLE
用のソースツリーは
常に次のところで<quote>公開</quote>されています:
<ulink url="ftp://ftp.FreeBSD.org/pub/FreeBSD/FreeBSD-stable/">ftp://ftp.FreeBSD.org/pub/FreeBSD/FreeBSD-stable/</ulink></para>
<para>私たちはまた, tar/compress
でツリー全体を入手できる <command>wu-ftpd</command>
を使用しています. 例えば :</para>
<screen>usr.bin/lex</screen>
<para>に対して:</para>
<screen><prompt>ftp></prompt> <userinput>cd usr.bin</userinput>
<prompt>ftp></prompt> <userinput>get lex.tar</userinput></screen>
<para>とすることにより, ディレクトリ全体を tar
ファイルとして入手することができます.</para>
</listitem>
</orderedlist>
</listitem>
<listitem>
<para>基本的には,
ソースに迅速でオンデマンドなアクセスが必要で,
接続のバンド幅が問題でなければ, <command>cvsup</command>
か <command>ftp</command> を使いましょう. そうで
ない場合は <application>CTM</application>
を使いましょう.</para>
</listitem>
<listitem>
<para>stable をコンパイルする前に,
<filename>/usr/src</filename> にある Makefile をよ
く読んでください.
少なくとも一回はアップグレードの処理の一部として最初に
<link linkend="makeworld">make world</link>
を実行するべきでしょう. &a.stable; を読めば,
次のリリースに移行する
に当たって時々必要となる既存システムからの
新システムの構築手順に
ついての最新情報が得られるでしょう.</para>
</listitem>
</orderedlist>
</sect3>
</sect2>
</sect1>
<sect1 id="synching">
<title>ソースの同期</title>
<para><emphasis>訳: &a.jp.iwasaki;. 13 September 1997.</emphasis></para>
<para>インターネット接続 (または電子メール) を使用して,
あなたの興味の対象によって FreeBSD
プロジェクトのソースのある一部分または全体の最新を
追いかける方法は色々あります.
私たちが提供している基本的なサービスは <link
linkend="anoncvs">Anonymous CVS</link>, <link
linkend="cvsup">CVSup</link> と <link linkend="ctm">CTM</link>
です:</para>
<warning>
<para>ソースツリーの一部を最新のものに更新することは可能です.
ただし, サポートされているアップデート手順は,
ソースツリー全体を最新のものに更新して,
ユーザランド (<filename>/bin</filename> や <filename>/sbin</filename>
にあるような, ユーザが実行するプログラム全体のこと)
およびカーネルのソースから再構築することのみであることに注意してください.
カーネルだけ, あるいはユーザランドだけというように,
ソースツリーの一部を更新した場合は, 問題が生じることがよくあります.
この時に発生する問題はコンパイル時のエラーからカーネルパニック,
データの破壊とさまざまです.</para>
</warning>
<para><application>Anonymous CVS</application> と
<application>CVSup</application> は <emphasis>pull</emphasis>
同期モデルを採用しています.
<application>CVSup</application> の場合, ユーザ
(または cron スクリプト) が <command>cvsup</command>
起動し, どこかにある <command>cvsupd</command>
サーバとやりとりしてファイルを
最新状態にします.
届けられる更新情報はその時点の最新のものであり,
また必要な時にだけ取り寄せられます.
興味のある特定のファイルやディレクトリに
限定して更新することも簡単にできます.
クライアント側のソースツリーの状態・
設定ファイルの指定に従い, サーバによって更新情報が
素早く生成されます.
<application>Anonymous CVS</application> は,
このプログラムがリモートの CVS リポジトリから直接変更点を
pull できるようにした &man.cvs.1; への拡張であるという点で,
<application>CVSup</application> よりもずっと単純です.
<application>CVSup</application>
は効率の点ではるかにまさっていますが,
<application>Anonymous CVS</application> の方が簡単に利用できます.
</para>
<para>一方, <application>CTM</application>
はあなたが持っているソースとマスタアーカイブ上に
あるそれとの対話的な比較をおこないませんし,
あるいは向こう側から変更点を pull したりもしません.
そのかわりに, 前回の実行時からの変更を認識するスクリプトが
マスタ CTM マシン上で一日に数回実行され,
すべての変更を compress して通し番号を振り,
さらに電子メールで転送できるようにエンコードします
(印字可能な ASCII
キャラクタのみです). 受信した後は,
これらの <quote>CTM のデルタ</quote> は自動
的にデコード, 検査してユーザのソースのコピーに変更を適用する
&man.ctm.rmail.1; によって処理可能となります.
この処理は <application>CVSup</application> や
<application>Anonymous CVS</application> よりずっと効率
的であり, <emphasis>pull</emphasis> モデルというよりむしろ
<emphasis>push</emphasis> モデルで
あるため, 私たちのサーバ資源の負荷は軽くなります.</para>
<para>もちろん他のトレードオフもあります. うっかりアーカイブ
の一部を消してしまっても, <application>CVSup</application>
は壊れた部分を検出して再構築してくれます.
<application>CTM</application> はこれをやってくれませんし,
<application>Anonymous CVS</application>
はおそらく他の何よりも深く混乱してしまうことが多いでしょう.
もしソースツリーの一部を消してしまったら, (最新の CVS
<quote>ベースデルタ</quote>から) 一からやり直し, CTM か anoncvs
を使って悪い部分を消去し, 再同期させることによって
すべてを再構築しなければなりません.</para>
<para><application>Anonymous CVS</application>,
<application>CTM</application>, <application>CVSup</application>
についての 詳しい情報については,
以下の節を参照してください.</para>
</sect1>
<sect1 id="makeworld">
<title><command>make world</command> の利用</title>
<para>FreeBSD のどれか特定のバージョン (<literal>stable</literal>,
<literal>current</literal> など)
について, ローカルのソースツリーを同期させたら,
そのソースツリーを使ってシステムを
再構築しなければなりません.</para>
<warning>
<title>バックアップを作成する</title>
<para>システムを再構築する<emphasis>前に</emphasis>バックアップを
作成することの重要性は, いくら強調してもし過ぎると言うことはありません.
システム全体の再構築とは
(以降に書かれた手順に従っている限り)難しい作業ではありませんが,
どんなに注意していたとしても, <!-- hrs:2000/01/12 inevitably -->
あなた自身, あるいはソースツリーで作業している他の人達に手違いがあった時には,
システムが起動しなくなってしまう状態になることがあるのです.
</para>
<para>まず, バックアップがきちんと作成されていることを確認して下さい.
そして, fix-it フロッピーを用意して下さい. 私は今までに,
一度もバックアップや fix-it フロッピーのお世話になったことはありませんし,
これからもそうなるようなことはないと思っていますが,
どういう場合であっても用意しておいて損はないでしょう.
</para>
</warning>
<warning>
<title>メーリングリストに参加する</title>
<para>もともと, -STABLE と -CURRENT のコードブランチは,
<emphasis>開発中のもの</emphasis>です.
FreeBSD の作業に貢献してくださっている人達も人間ですから,
時にはミスをすることだってあるでしょう.
</para>
<para>そのような間違いは, 単に警告を示す見慣れない
診断メッセージをシステムが,表示するような,
全く害のないものであることもあれば, システムを起動できなくしたり,
ファイルシステムを破壊してしまうような,
恐ろしい結果を招くものかも知れません.
</para>
<para>万が一, このような問題が生じた場合,
問題の詳細と, どのようなシステムが影響を受けるかについて書かれた
<quote>注意(heads up)</quote>の記事が
適切なメーリングリストに投稿され, そして, その問題が解決されると,
<quote>問題解決(all clear)</quote>のアナウンス記事が同様に
投稿されます.
</para>
<para>-STABLE や -CURRENT ブランチを試したり, それらに
追随していくときに
<email>FreeBSD-stable@FreeBSD.ORG</email> や
<email>FreeBSD-current@FreeBSD.ORG</email>
を読まないというのは, 自ら災難を招くことになるでしょう.
</para>
<para><emphasis>訳注:</emphasis>
これらのメーリングリストは英語でやりとりされているため,
日本語での投稿は歓迎されません. 英語でのやりとりができない人は,
<ulink url="http://www.jp.FreeBSD.org">FreeBSD 友の会</ulink>
の運営しているメーリングリストをあたってみるのがいいでしょう.
</para>
</warning>
<sect2>
<title><filename>/usr/src/UPDATING</filename> を読む</title>
<para>何を始めるにしろ, まず最初に
<filename>/usr/src/UPDATING</filename> (もしくはあなたがソースコードを
どこにコピーしたにせよそれに相当するファイル) を読みましょう.
このファイルにはあなたが遭遇するかも知れない問題に対する重要な情報を
含んでいたり, あなたが特定のコマンドを実行しなければならなくなった時
その順序を指示したりするはずです.
<filename>UPDATING</filename> があなたが読んだ事柄と矛盾している時は
<filename>UPDATING</filename> が優先します.</para>
<important>
<para><filename>UPDATING</filename> を読むということは, 前述の
適切なメーリングリストを購読する代わりにはなりません.
二つの要求は相補的なもので排他的なものではないのです.</para>
</important>
</sect2>
<sect2>
<title><filename>/etc/make.conf</filename> の確認</title>
<para>まず, <filename>/etc/defaults/make.conf</filename> と
<filename>/etc/make.conf</filename> を調べてください. そこには
最初から標準的なものが (多くのものはコメントアウトされていますが)
含まれています. ソースからシステムを再構築するときに make が
<filename>/etc/make.conf</filename> に付け加えられた設定を使用します.
<filename>/etc/make.conf</filename> に追加された設定は <command>make
</command> を実行したときに常に使われることを覚えておいてください.
そのため, システムに必要な設定を書いておくと良いでしょう.</para>
<para>(FreeBSD の開発者でない) 標準的なユーザならおそらく,
<filename>/etc/defaults/make.conf</filename> の <makevar>CFLAGS</makevar> と
<makevar>NOPROFILE</makevar> のコメントをはずすことを考えると思います.</para>
<note>
<title/FreeBSD 2.1.7 以前の場合/
<para>もし, 浮動小数点演算ユニット(386DX, 486DX, Pentium と,
それより上のクラスのマシン)がある場合には, HAVE_FPU
の行のコメントをはずすことができます.
</para>
<!-- hrs:2000/01/13 386DX doesn't have FPU. -->
<para>この定義は, FreeBSD 2.2.2 以降で廃止されました.
</para>
</note>
<para>他の定義 (COPTFLAGS, NOPORTDOCS など) の定義行についても,
コメントを外す必要があるかどうか調べておきましょう.
</para>
</sect2>
<sect2>
<title><filename>/etc/group</filename> の更新</title>
<para>
<filename>/etc</filename> ディレクトリには,
システム起動時に実行されるスクリプトだけでなく,
あなたのシステムの設定に関連する情報の大部分が
含まれています. そのディレクトリに含まれる
スクリプトは, FreeBSD のバージョンによって多少異なります.
</para>
<para>
また, 設定ファイルのなかには, 稼働中のシステムが日々利用している
ものもあります. 実際には, <filename>/etc/group</filename>
などがそれに該当します.
</para>
<para>
<quote>make world</quote> のインストールの段階では,
特定のユーザ名, あるいはグループが存在していることを
要求する場面があります. システムのアップグレードを行なう際には,
それらのグループが削除, あるいは変更されて存在していない可能性が
考えられますが, そういった場合, システムのアップグレードを
行なっている間に, 問題が発生する原因になります.
</para>
<para>この種の例でもっとも記憶に新しいのは,
<quote/ppp/ グループ(後に <quote/network/ に変更されました)が
追加された時です.
<filename>ppp</filename> サブシステムがインストールされる時,
そのサブシステムが利用する <quote/ppp/ グループが存在しなかったために,
それらのインストールに失敗してしまったのです.
</para>
<para>解決方法は, <filename>/usr/src/etc/group</filename> を調べ,
自分のシステムのグループ名リストと比較することです.
最新のファイルに含まれていて, あなたのファイルに含まれていない
グループ名があれば, あなたのファイルにそのグループ名をコピーして下さい.
同様に, 名前が異なるにも関わらず,
<filename>/etc/group</filename> と
<filename>/usr/src/etc/group</filename> で同じ GID を持っているグループ名があれば,
<filename>/etc/group</filename> に含まれる,
該当するすべてのグループ名を変更しておかなければなりません.
</para>
<tip>
<para>もし, あなたがもっと神経質な人なら, あなたが名前を変更したり,
削除してしまったグループが所有しているファイルを,
次のようにして調べることもできます.
</para>
<screen>&prompt.root; <userinput>find / -group <replaceable>GID</replaceable> -print</userinput></screen>
<para>これは <replaceable>GID</replaceable>(グループ名もしくは数字で示されたグループ ID)で
指定されたグループが所有するすべてのファイルを表示します.
</para>
</tip>
</sect2>
<sect2>
<title/シングルユーザモードへの移行/
<para>コンパイルは, シングルユーザモードで行なった方が良いでしょう.
そうすることで多少速度が向上する, というちょっとした利点が
あるだけでなく, システムの再インストールは重要なシステムファイル,
標準コマンド, ライブラリ, インクルードファイルなどを操作します.
稼働中のシステムに(特に他のユーザがログインしている時に)そのような
変更を加えることは, トラブルを引き起こす原因となります.
</para>
<para>自信家の方は, このステップを省略しても構いません.</para>
<note>
<title>FreeBSD 2.2.5-RELEASE 以降の場合</title>
<para>以下に詳しく述べられているように, 2.2.5-RELEASE 以降,
ビルド(システムの構築)とインストールの行程を分離して行なうことが可能になりました.
そのため, マルチユーザモードで新しいシステムの<emphasis>ビルド</emphasis>を行ない,
その後, シングルユーザモードに移行してから
インストールを行なうことができます.
</para>
</note>
<para>稼働中のシステムでシングルユーザモードに移行するには,
スーパユーザ(root)権限で次のコマンドを実行します.</para>
<screen>&prompt.root; <userinput/shutdown now/</screen>
<para>あるいはシステムを再起動し, ブートプロンプトから
<option>-s</option> フラグを設定することで, シングルユーザモードで
システムを起動させることができます. 起動後, シェルプロンプトから
次のように実行して下さい.
</para>
<screen>&prompt.root; <userinput>fsck -p</userinput>
&prompt.root; <userinput>mount -u /</userinput>
&prompt.root; <userinput>mount -a -t ufs</userinput>
&prompt.root; <userinput>swapon -a</userinput></screen>
<para>これはファイルシステムをチェックした後,
<filename>/</filename> を読み書き可能にして再マウント,
<filename>/etc/fstab</filename> に指定されている,
それ以外の UFS ファイルシステムをすべてマウントしてから
スワップを有効にします.
</para>
</sect2>
<sect2>
<title><filename>/usr/obj</filename> の削除</title>
<para>システムが再構築される時, 構築されたものは(デフォルトで)
<filename>/usr/obj</filename> 以下のディレクトリに格納され,
そのディレクトリの下は <filename>/usr/src</filename> と同じ構造となります.
</para>
<para>このディレクトリをあらかじめ削除しておくことにより,
<quote>make world</quote> の行程にかかる時間を短縮させ,
依存問題に悩まされるようなトラブルを回避することができます.
</para>
<para><filename>/usr/obj</filename> 以下のファイルには,
変更不可(immutable)フラグ(詳細は
&man.chflags.1; 参照)がセットされているものがあります.
そのため, まず最初にそのフラグを変更しなければなりません.
</para>
<screen>&prompt.root; <userinput>cd /usr/obj</userinput>
&prompt.root; <userinput>chflags -R noschg *</userinput>
&prompt.root; <userinput>rm -rf *</userinput></screen>
</sect2>
<sect2>
<title/ソースの再構築と新しいシステムのインストール/
<sect3>
<title>全バージョンに共通すること</title>
<para>まず, カレントディレクトリを <filename>/usr/src</filename> に
変更しなければなりません. 次のように実行して下さい.</para>
<screen>&prompt.root; <userinput>cd /usr/src</userinput></screen>
<para>(もちろん, ソースコードが他のディレクトリにある場合には,
<filename>/usr/src</filename> ではなく,
ソースコードのあるディレクトリに移動して下さい).
</para>
<para>
make world を行なうには, &man.make.1; コマンドを使用します.
このコマンドは, <filename>Makefile</filename> というファイルから,
FreeBSD を構成するプログラムの再構築方法や,
どういう順番でそれらを構築すべきかといったような
指示を読み込みます.
</para>
<para>
コマンドラインの一般的な書式は, 次のとおりです.
</para>
<screen>&prompt.root; <userinput>make <option>-<replaceable/x/</option> <option>-D<replaceable>VARIABLE</replaceable></option> <replaceable>target</replaceable></userinput></screen>
<para>
この例では, <option>-<replaceable>x</replaceable></option> が
&man.make.1; に渡されるオプションになります.
どのようなオプションが利用できるかについては, マニュアルページを
参照して下さい.
</para>
<para>
<option>-D<replaceable>VARIABLE</replaceable></option> は,
<filename>Makefile</filename> に渡される変数であり,
この変数は <filename>Makefile</filename> の動作をコントロールします.
また, <filename>/etc/make.conf</filename> で設定される変数も
同様です. これは変数を設定するもう一つの方法として用意されています.
</para>
<screen>&prompt.root; <userinput>make -DNOPROFILE=true <replaceable>target</replaceable></userinput></screen>
<para>
は, プロファイル版のライブラリを構築しないことを指定する
もう一つの記法で, <filename>/etc/make.conf</filename> 中の</para>
<programlisting>NOPROFILE= true
# Avoid compiling profiled libraries</programlisting>
<para>の行に対応します.</para>
<para>
<replaceable>target</replaceable> は, &man.make.1; に
どのように動作するのかを指示するためのものです.
各々の <filename>Makefile</filename> には, 数多くの異なる
<quote>ターゲット(target)</quote> が定義されていて,
指定されたターゲットによって, 動作が決まります.
</para>
<para>
<filename>Makefile</filename> に書かれているターゲットには,
あなたが指定しても意味を持たないものも含まれます.
これらは, システムの再構築に必要な段階を, 多くの
さらに細かい段階に分割するため, 構築の過程で利用されるものです.
</para>
<para>
大抵の場合, &man.make.1; にパラメータを指定する必要はないでしょうから,
コマンドラインは次のようなものになるでしょう.
</para>
<screen>&prompt.root; <userinput>make <replaceable>target</replaceable></userinput></screen>
</sect3>
<sect3>
<title>出力の保存</title>
<para>
実行される &man.make.1; からの出力は, ファイルに保存すると良いでしょう.
もし, 何か障害が発生した場合, エラーメッセージのコピーに加え,
どの時点でそれが起こったのか, 完全なリストが手元に残ります.
<!-- hrs:2000/02/14 (for ja-translators)
had got to == reach, but translated "where the problem happened" -->
何が悪かったのか, あなた自身がそれから理解することはできないかも
知れません. しかし, FreeBSD メーリングリストに投稿して,
誰か他の人からの助言を得るために利用することができます.
</para>
<para>
ファイルに保存する最も簡単な方法は, &man.script.1; コマンドを
使い, 引数に出力を保存したいファイル名を指定することです.
これを make world の直前に行ない, 再構築が終了してから
<userinput>exit</userinput> と入力すると, 出力を保存することができます.
</para>
<screen>&prompt.root; <userinput>script /var/tmp/mw.out</userinput>
Script started, output file is /var/tmp/mw.out
&prompt.root; <userinput>make world</userinput>
<emphasis>… compile, compile, compile …</emphasis>
&prompt.root; <userinput>exit</userinput>
Script done, …</screen>
<para>
出力を保存する場合, <filename>/tmp</filename> ディレクトリの中に
保存しては<emphasis>いけません</emphasis>.
このディレクトリは, 次の再起動で削除されてしまう可能性があります.
出力の保存には, (上の例のように)<filename>/var/tmp</filename>や
<username>root</username> のホームディレクトリが適しています.
</para>
</sect3>
<sect3>
<title>FreeBSD-2.2.2 と, それ以前のバージョン</title>
<para>
<filename>/usr/src/Makefile</filename> には,
システム全体を再構築しインストールを行なう
<maketarget>world</maketarget> ターゲットが含まれています.
</para>
<para>
それを, 次のように使って下さい.
</para>
<screen>&prompt.root; <userinput>make world</userinput></screen>
</sect3>
<sect3>
<title>FreeBSD-2.2.5 と, それ以降のバージョン</title>
<para>
FreeBSD-2.2.5 から(実際には, -CURRENT ブランチで最初に作成され,
2.2.2 と 2.2.5 の間の時点で -STABLE に導入されたのですが),
<maketarget>world</maketarget> ターゲットは
<maketarget>buildworld</maketarget> と
<maketarget>installworld</maketarget> の二つに分割されました.
</para>
<para>
その名前が示すように, <maketarget>buildworld</maketarget> は
<filename>/usr/obj</filename> 以下に新しい完全な
ディレクトリツリーを構築し,
<maketarget>installworld</maketarget> は, そのツリーを
現在のマシンにインストールします.
</para>
<para>
これは, 二つの理由から非常に有用です.
まず第一に, 稼働中のシステムに全く影響を与えることなく,
安全にシステムの構築作業を行えることです.
構築作業は<quote>何にも依存せず独立して行なわれる</quote>ため,
<!-- hrs:2000/02/14: needs good phrase that means "self hosted" -->
マルチユーザモードで稼働中のシステムでも, 何一つ
悪影響を与えずに <maketarget>buildworld</maketarget> を
実行することができます.
ただし, <maketarget>installworld</maketarget> は
シングルユーザモードで行なうことをおすすめします.
</para>
<para>
第二に, NFS マウントを利用することで,
ネットワーク上の複数のマシンをアップグレードすることが
可能な点があげられます. 例えば三台のマシン, マシン A, マシン B,
マシン C をアップグレードしたい場合には, まず
マシン A で <command>make buildworld</command> と
<command>make installworld</command> を実行します.
それから, マシン B とマシン C で <filename>/usr/src</filename> を
NFS マウントし, <command>make installworld</command> とすることで
構築済みのシステムを各マシンにインストールすることができるのです.
</para>
<para>
一方, <maketarget>world</maketarget> ターゲットも残されていますので,
FreeBSD-2.2.2 の場合として示されている方法と同じように,
このターゲットを利用することもできます.
<command>make world</command> は,
<command>make buildworld</command> に続けて
<command>make installworld</command> を実行します.
</para>
<note>
<para>
<command>make buildworld</command> と
<command>make installworld</command> のコマンドを分けて実行する場合には,
それぞれ同じ引数を &man.make.1; に渡さなければなりません.
</para>
<para>次のように実行したとすると,</para>
<screen>&prompt.root; <userinput>make -DNOPROFILE=true buildworld</userinput></screen>
<para>構築されたシステムは次のようにしてインストールする必要があります.</para>
<screen>&prompt.root; <userinput>make -DNOPROFILE=true installworld</userinput></screen>
<para>そうしないと, <command>make buildworld</command> の段階で
構築されていない, プロファイル版ライブラリのインストールを
試みることになります.
(訳注: もちろん, それには失敗するのでエラーが発生します. )
</para>
</note>
</sect3>
<sect3>
<title>-CURRENT と, それ以降</title>
<para>
もし, -CURRENT を追跡しているなら, <command>make</command> コマンドに
<option>-j</option> オプションを渡すことができます.
このオプションにより, <command>make</command> は
同時に複数のプロセスを生成するようになります.
</para>
<para>
これは, 実際に複数の CPU を備えているマシンに対して
非常に有効に働きます. また, コンパイルプロセスの大部分は
CPU の処理ではなく入出力の処理に費やされるため,
単一の CPU を持つマシンでも同じように有効です.
</para>
<para>単一の CPU を持つ典型的なマシンでは, 次のように実行します. </para>
<screen>&prompt.root; <userinput>make -j4 <replaceable>target</replaceable></userinput></screen>
<para>
この時 &man.make.1; は, 最大 4 個までのプロセスを同時に実行します.
メーリングリストに投稿された経験的な報告によると,
4 個という指定が最も良いパフォーマンスを示すようです.
</para>
<para>
もし, 複数の CPU を備えたマシンで SMP 設定が行なわれたカーネルを
利用しているなら, 6 から 10 の間の値を設定し, 速度がどれくらい
向上するか確認してみて下さい.
</para>
<para>
注意して欲しいのですが, (この原稿を書いている時点では)この機能はまだ
実験段階です. そのため, ソースツリーへ変更が加えられたときに
これが正常に機能しなくなる可能性があります.
もし, このオプションを用いてシステムの構築に失敗した場合には,
障害を報告する前に, もう一度オプションを付けずに試してみて下さい.
</para>
</sect3>
<sect3
<title>システムの構築にかかる時間</title>
<para>
すべてが順調に進んでいたとしても,
一時間半から丸一日程度の時間がかかります.
</para>
<para>
一般的に言って, 200MHz の P6(訳注: Intel PentiumPro のこと) で
32MB 以上のメモリを搭載し, 標準的な SCSI ディスクドライブを利用していた
とすると, <command>make world</command> の完了までに
およそ一時間半の時間がかかります. この構成よりも性能が低ければ,
それよりもさらに時間がかかるでしょう.
</para>
</sect3>
</sect2>
<sect2>
<title><command>make world</command> で更新されないファイルの更新</title>
<para>
システムの再構築は, いくつかのディレクトリ (
特に, <filename>/etc</filename>, や <filename>/var</filename> や
<filename>/usr</filename>) において,
新規に導入されたり, 変更された設定ファイルによる
ファイルの更新は行なわれません.</para>
<para>
これらのファイルを更新するもっとも簡単な方法は, &man.mergemaster.8;
を使うことです. これは自分でやることも可能なので, そうしても
かまいません.
&man.mergemaster.8; は簡単に使えるので, こちらを使うことを
お勧めします. その場合には <link linkend="update-dev">
次のセクション</link> に進んでください.
まず最初にマニュアルページを読んで, <filename>/etc</filename>
のバックアップを取って不測の事態に備えてください.
</para>
<para>
手動で更新することを選んだ場合,
単にファイルを
<filename>/usr/src/etc</filename> から <filename>/etc</filename> に
コピーしただけでは正常に動作させることはできません.
これらのファイルには, <quote>インストールという
手順を踏まなければならないもの</quote>が含まれています.
<filename>/usr/src/etc</filename> ディレクトリは
<filename>/etc</filename>
ディレクトリにそのまま置き換えられるような
コピーでは<emphasis>ない</emphasis>からです.
また, <filename>/etc</filename> にあるべきファイルのうちで
<filename>/usr/src/etc</filename> にないものもあります.
</para>
<para>
手動で行う際の
一番簡単な方法は, ファイルを新しいディレクトリにインストールしてから,
以前のものと異なっている部分を調べて更新作業を行なうことです.
</para>
<warning>
<title>既存の <filename>/etc</filename> をバックアップする</title>
<para>
理論的に考えて, このディレクトリが自動的に
処理されることはありませんが, 念には念を入れておいて
損はありません. たとえば以下のようにして,
既存の <filename>/etc</filename> ディレクトリを
どこか安全な場所にコピーしておきましょう.
</para>
<screen>&prompt.root; <userinput>cp -Rp /etc /etc.old</userinput></screen>
<para>
<option>-R</option> は再帰的なコピーを行ない,
<option>-p</option> はファイルの更新時間や所有者などを保存します.
</para>
</warning>
<para>
また, 新しい <filename>/etc</filename> やその他のファイルを
インストールするための, 仮のディレクトリを作っておく必要があります.
私はいつもこの仮のディレクトリを
<filename>/var/tmp/root</filename> に置くことにしています.
同様に, 必要なサブディレクトリもこの下に置きます.</para>
<screen>&prompt.root; <userinput>mkdir /var/tmp/root</userinput>
&prompt.root; <userinput>cd /usr/src/etc</userinput>
&prompt.root; <userinput>make DESTDIR=/var/tmp/root distrib-dirs distribution</userinput></screen>
<para>
上の例は, 必要なディレクトリ構造をつくり, ファイルをインストールします.
<filename>/var/tmp/root</filename> 以下に作られる,
たくさんの空のディレクトリは削除する必要があります.
一番簡単なやり方は, 次のとおりです. </para>
<screen>&prompt.root; <userinput>cd /var/tmp/root</userinput>
&prompt.root; <userinput>find -d . -type d | xargs rmdir 2>/dev/null</userinput></screen>
<para>
これは空ディレクトリをすべて削除します.
(空でないディレクトリに関する警告を避けるために,
標準エラー出力は <filename>/dev/null</filename> に
リダイレクトされます)
</para>
<para>
この段階の <filename>/var/tmp/root</filename> には,
本来 <filename>/</filename> 以下にあるべきファイルが
すべて含まれています.
各ファイルを順に見て, 既存のファイルと異なる部分を
調べて下さい.
</para>
<para>
<filename>/var/tmp/root</filename> 以下に
インストールされているファイルの中には,
<quote/./ から始まっているものがあります.
これを書いている時点で, それに該当するファイルは
<filename>/var/tmp/root/</filename> と
<filename>/var/tmp/root/root/</filename> の中にある
シェルスタートアップ ファイルだけですが,
他のものがあるかも知れません.
(これは, あなたがこれをどの時点で読んでいるかに依存するので,
<command/ls -a/ を使って確かめてください)</para>
<para>
もっとも簡単な方法は, 二つのファイルを比較するコマンド
&man.diff.1; を使うことです.
</para>
<screen>&prompt.root; <userinput>diff /etc/shells /var/tmp/root/etc/shells</userinput></screen>
<para>
これは, あなたの
<filename>/etc/shells</filename> ファイルと
新しい <filename>/etc/shells</filename> ファイルの
異なる部分を表示します.
これらを, あなたが書き換えたものに変更点をマージするか,
それとも既存のファイルを新しいもので上書きするかを
判断する材料にして下さい.
</para>
<tip>
<title>新しい root ディレクトリ
(<filename>/var/tmp/root</filename>) の名前に
タイムスタンプを付けておくと,
異なるバージョン間の比較を楽に行なうことができます. </title>
<para>
頻繁にシステムの再構築を行なうということは,
<filename>/etc</filename> の更新もまた, 頻繁に行う必要がある
ということです. これはちょっと手間のかかる作業です.
</para>
<para>
この作業は, あなたが <filename>/etc</filename> にマージした,
新しく変更されたファイルの最新のセットのコピーを保存しておくことで
素早く行なうことができます.
下の手順は, それを実現するための一つの方法です. </para>
<procedure>
<step>
<para>
普通に make world します. <filename>/etc</filename> や
他のディレクトリを更新したくなったときは, ターゲット
ディレクトリに, そのときの日付に基づく名前をつけてください.
たとえば 1998 年 2 月 14 日 だとすれば, 以下のようにします.
</para>
<screen>&prompt.root; <userinput>mkdir /var/tmp/root-19980214</userinput>
&prompt.root; <userinput>cd /usr/src/etc</userinput>
&prompt.root; <userinput>make DESTDIR=/var/tmp/root-19980214 \
distrib-dirs distribution</userinput></screen>
</step>
<step>
<para>
上に説明されているように,
このディレクトリから変更点をマージします.
</para>
<para>
その作業が終了しても,
<filename>/var/tmp/root-19980214</filename> を
削除しては<emphasis>いけません</emphasis>. </para>
</step>
<step>
<para>
最新版のソースをダウンロードして再構築したら,
ステップ 1 にしたがって下さい. 今度は,
<filename>/var/tmp/root-19980221</filename>
(更新作業が一週間おきだった場合)
のような名前の, 新しいディレクトリをつくることになるでしょう.
</para>
</step>
<step>
<para>
この段階で &man.diff.1; を使用し,
二つのディレクトリを比較する再帰的 diff を作成することで,
一週間の間に行なわれたソースへの変更による相違点を調べます.
</para>
<screen>&prompt.root; <userinput>cd /var/tmp</userinput>
&prompt.root; <userinput>diff -r root-19980214 root-19980221</userinput></screen>
<para>
これによって報告される相違点は, 大抵の場合,
<filename>/var/tmp/root-19980221/etc</filename> と
<filename>/etc</filename> との場合に比べて
非常に少ないものになります.
相違点が少ないため, 変更点を既存の <filename>/etc</filename>
ディレクトリにマージすることは, 比較的容易になります.
</para>
</step>
<step>
<para>
ここまで終了したら, <filename>/var/tmp/root-*</filename> の
二つのうち, 古い方のディレクトリは削除して構いません.
</para>
<screen>&prompt.root; <userinput>rm -rf /var/tmp/root-19980214</userinput></screen>
</step>
<step>
<para>
この工程を, <filename>/etc</filename> へ変更点をマージする
必要があるたび, 毎回繰り返します.
</para>
</step>
</procedure>
<para>
ディレクトリ名の生成を自動化するには, &man.date.1;
を利用することができます.
</para>
<screen>&prompt.root; <userinput>mkdir /var/tmp/root-`date "+%Y%m%d"`</userinput></screen>
</tip>
</sect2>
<sect2 id="update-dev">
<title><filename>/dev</filename> の更新</title>
<note>
<title>DEVFS</title>
<para>
もし, DEVFS を利用しているなら, この作業はおそらく必要ないでしょう.
</para>
</note>
<para>
安全のため, これはいくつかの段階に分けて行ないます.
</para>
<procedure>
<step>
<para>
<filename>/var/tmp/root/dev/MAKEDEV</filename> を
<filename>/dev</filename> にコピーします.
</para>
<screen>&prompt.root; <userinput>cp /var/tmp/root/dev/MAKEDEV /dev</userinput></screen>
<para>
<filename>/etc</filename> を更新するのに
&man.mergemaster.8; を使った場合,
<filename>MAKEDEV</filename> スクリプトは既に更新
されているでしょうが, (&man.diff.1; を使って)
チェックすることは無駄ではありませんし,
必要なら自分でコピーしてください.
</para>
</step>
<step>
<para>
ここで, <filename>/dev</filename> のファイル一覧を記録しておきます.
この一覧は, 各ファイルの許可属性, 所有者, メジャー番号, マイナー番号が
含まれている必要がありますが, タイムスタンプは含まれていてはいけません.
これを行なう簡単な方法は, &man.awk.1; を使って,
いくつかの情報を取り除くことです.
</para>
<screen>&prompt.root; <userinput>cd /dev</userinput>
&prompt.root; <userinput>ls -l | awk '{print $1, $2, $3, $4, $5, $6, $NF}' > /var/tmp/dev.out</userinput></screen>
</step>
<step>
<para>デバイスファイルをつくり直します. </para>
<screen>&prompt.root; <userinput/sh MAKEDEV all/</screen>
</step>
<step>
<para>
もう一度, ディレクトリのファイル一覧を記録します.
今回は <filename>/var/tmp/dev2.out</filename> です.
この段階で, この二つのファイル一覧を調べて
作成に失敗したデバイスを探して下さい.
違いは一つもないはずなのですが, 安全のために一応チェックして下さい.
</para>
<screen>&prompt.root; <userinput>diff /var/tmp/dev.out /var/tmp/dev2.out</userinput></screen>
<para>
次のようなコマンドを使用し, ディスクスライスエントリを
再作成することで, ディスクスライスの矛盾を検出することができます.
<screen>&prompt.root; <userinput>sh MAKEDEV sd0s1</userinput></screen>
適当な組み合わせは, 環境によって異なります.
</para>
</step>
</procedure>
</sect2>
<sect2>
<title><filename>/stand</filename> の更新</title>
<note>
<para>
この段階は, 完全な更新を行なう場合にだけ必要な内容を含んでいます.
悪影響はありませんので, 省略しても構いません.
</para>
</note>
<para>
完全な更新を行なうために,
<filename>/stand</filename> にあるファイルも同じように
更新したいと考えるかも知れません.
これらのファイルは, <filename>/stand/sysinstall</filename> という
バイナリファイルへのハードリンクです. このバイナリファイルは,
他のファイルシステム(特に <filename>/usr</filename>)が
マウントされていない場合にも動作できるよう,
静的にリンクされていなければなりません.
</para>
<screen>&prompt.root; <userinput>cd /usr/src/release/sysinstall</userinput>
&prompt.root; <userinput>make all install</userinput></screen>
<note>
<title>1998 年 4 月 2 日以前のソースの場合</title>
<para>
もし, 1998 年 4 月 2 日より古いソースコードを使っているか,
<filename>Makefile</filename> のバージョンが 1.68
以降(FreeBSD-CURRENT および FreeBSD-3.X の場合),
1.48.2.21 以降(FreeBSD-2.2.X の場合)でなければ,
次のように <userinput>NOSHARED=yes</userinput>
オプションを追加する必要があります.
</para>
<screen>&prompt.root; <userinput>make NOSHARED=yes all install</userinput></screen>
</note>
</sect2>
<sect2>
<title>新しいカーネルのコンパイルとインストール</title>
<para>
新しいシステムにおけるアドバンテージを完全に得るために,
カーネルの再コンパイルをすべきです.
再コンパイルは, ある種のメモリ構造が変更された時には必須です.
その場合, &man.ps.1; や &man.top.1; のようなプログラムは,
カーネルとソースコードのバージョンが一致しないと
正常に動作しないでしょう.
</para>
<para>
新しい kernel をコンパイルするには,
FreeBSD ハンドブックの指示にしたがってください.
過去に自分で設定したカーネルを構築している場合には,
<filename>LINT</filename> コンフィグレーションファイルを注意深く調べて,
利用できる新しいオプションがあるかどうか確かめて下さい.
</para>
<para>
この文書の以前の版では,
カーネルの再構築の前に再起動することを推奨していました.
これは以下の点で誤りです.
</para>
<itemizedlist>
<listitem>
<para>&man.ps.1;, や &man.ifconfig.8;,
&man.sysctl.8; といったコマンドが動作しなくなる恐れがあります.
そうなると, マシンがネットワークに接続できなくなってしまいます.
</para>
</listitem>
<listitem>
<para>&man.mount.8; のような基本的なユーティリティが機能しなくなり,
<filename>/</filename> や <filename>/usr</filename> 等を
マウントできなくなってしまうかも知れません.
これは, -STABLE の候補を追いかけている場合には
あまり発生することはありませんが,
-CURRENT を追いかけていて,
大規模なマージが行なわれている間には良く起こります.
</para>
</listitem>
<listitem>
<para>
ローダブルカーネルモジュール (FreeBSD-3.X 以前は
LKM と呼ばれていましたが, FreeBSD-3.X 以降は KLD
と呼んでいます)は <quote>world</quote> の一部として
構築されるため, 古いカーネルがクラッシュする可能性があります.
</para>
</listitem>
</itemizedlist>
<para>
これらの理由から, どんな場合においても,
再起動する前に新しいカーネルを再構築し, インストールすることが
最も良い手順になります.
</para>
<para>
新しいカーネルは, <userinput>make world</userinput>
(あるいは <userinput>make installworld</userinput>) が完了した後で
構築しなければなりません. もし, そうしない場合には
(おそらく, あなたはシステムを更新する前にカーネルが構築されることを
確認したいのでしょう) 問題が起こるかも知れません. それは,
カーネルソースに対して &man.config.8; コマンドが古いことが原因です.
</para>
<para>
その場合には, 新しいバージョンの &man.config.8;
でカーネルを構築することができます.
</para>
<screen>&prompt.root; <userinput>/usr/obj/usr/src/usr.sbin/config/config <replaceable>KERNELNAME</replaceable></userinput></screen>
<para>
これは, いつもうまく行くとは限りませんので,
新しいをカーネルをコンパイルする前に
<userinput>make world</userinput> (あるいは <userinput>make
installworld</userinput>)を完了させることが推奨されています. </para>
</sect2>
<sect2>
<title/再起動/
<para>
これで, 作業はおしまいです.
すべてがあるべき正しい場所に存在することをチェックしたら,
システムを再起動します. これは, 単に
&man.fastboot.8; を実行するだけです.
</para>
<screen>&prompt.root; <userinput>fastboot</userinput></screen>
</sect2>
<sect2>
<title>作業の完了</title>
<para>
ここまで来れば, FreeBSD システムのアップグレードは成功です.
おめでとうございます.
</para>
<para>
さて, この時点で, 今までの間違った操作による小さな問題に
気付くことがあるかも知れません.
たとえば, 私はかつて <filename>/etc/magic</filename>
をアップグレードの途中で削除し, そのまま
<filename>/etc</filename>
にマージしてしまったことがあります.
その結果, <command>file</command>
コマンドは動作しなくなってしまったのです.
すぐに思いついたのは, これを修復するには
<screen>&prompt.root; <userinput>cd /usr/src/usr.bin/file</userinput>
&prompt.root; <userinput/make all install/</screen>
だけで十分ではないか, ということでした. </para>
</sect2>
<sect2>
<title/質問ですか?/
<qandaset>
<qandaentry>
<question>
<para>変更が行なわれたら, その度にシステムの再構築が必要になるのでしょうか?</para>
</question>
<answer>
<para>
それは変更の性質によるので, なんとも言えません.
例えば, CVSup を実行したとき, 最後に実行したときから比べて
次にあげるようなファイルが更新されていたとします.</para>
<screen><filename>src/games/cribbage/instr.c</filename>
<filename>src/games/sail/pl_main.c</filename>
<filename>src/release/sysinstall/config.c</filename>
<filename>src/release/sysinstall/media.c</filename>
<filename>src/share/mk/bsd.port.mk</filename></screen>
<para>
このときには, 改めてシステムを再構築する必要はありません.
わたしなら, 適切なサブディレクトリに移って
<command>make all install</command> を行うと思います.
しかし, もし何らかの大きな変更が行なわれているとき, 例えば
<filename>src/lib/libc/stdlib</filename> が変更されている場合には,
システムを再構築するか, もしくはそのうち,
少なくとも静的にリンクされているもの(と, わたしが追加した
他のプログラムのうち, 静的にリンクされたもの)を
作り直すことでしょう.
</para>
<para>結局のところ, どの時点で現在のシステムをアップグレードするかは
あなたが決めることです.
2 週間ごとにシステムを再構築し, その 2 週間の変更を取り込めば
幸せかもしれませんし,
変更のあった部分だけ再構築し, 依存関係を確かめたいと考えるかも知れません.
<!-- hrs:2000/02/15
What's "every fortnight say"? s/say/day/? -->
</para>
<para>
もちろん, それらはどのくらいの頻度でアップグレードしたいか,
そして -STABLE か -CURRENT のどちらを追いかけているのかによります.
</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>signal 11(もしくは他のシグナル番号)のエラーがたくさん出て
コンパイルが失敗します. 何が起こっているんでしょうか?</para>
</question>
<answer>
<para>
これは通常, ハードウェアに問題があることを示しています.
システムの再構築は, ハードウェアに対する負荷耐久試験を行なうための
有効な手段の一つで, メモリに関係する問題がよく報告されます.
その大部分は, コンパイラが奇妙なシグナルを受け取り,
不可解な異常終了となることで発見されます.
</para>
<para>
本当にこの問題によるものかどうかは, 再構築をもう一度実行し,
異なる段階で異常終了が発生するか, ということから確認できます.
</para>
<para>
この場合には, マシンの部品を交換して, どの部分が悪いのかを
調べてみることくらいしかできることはありません.
</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>終了したら <filename>/usr/obj</filename> を削除しても
かまいませんか?</para>
</question>
<answer>
<para>
それはあなたが次の機会に,
システムの再構築をどう行なうつもりなのかによります.
</para>
<para><filename>/usr/obj</filename> には,
コンパイルの段階で生成された
すべてのオブジェクトファイルが含まれています.
通常 <quote/make world/ の最初の段階では,
このディレクトリを削除して新しくつくり直すようになっています.
その場合には, 構築終了後の <filename>/usr/obj</filename>
を保存しておいても, あまり意味はありません.
削除すれば, 大きなディスクスペースを
(現在はだいたい 150MB あります) 解放することができます. </para>
<para>
しかし, もしあなたが何を行なおうとしているのか理解しているなら,
この段階を省略して <quote/make world/ を行なうことができます.
こうすると, ほとんどのソースは再コンパイルされないため,
構築はかなり高速化されます.
これは裏をかえせば, デリケートな依存関係の問題によって,
システムの構築が奇妙な失敗に終わる可能性があるということです.
FreeBSD メーリングリストではしばしば, 構築の失敗が,
この段階の省略によるものだということを理解せずに
不満の声をあげる人がいます.
</para>
<para>
もし, このような危険を承知した上でシステムの再構築を行なう場合には,
次のように変数 <makevar>NOCLEAN</makevar> を定義して構築します.
</para>
<screen>&prompt.root; <userinput>make -DNOCLEAN world</userinput></screen>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>構築を中断した場合, その構築を途中から再開することはできますか?</para>
</question>
<answer>
<para>
それは, あなたが問題に気付く前に,
どれだけの作業を終えているかによって変わります.
</para>
<para><emphasis>一般的に</emphasis> (そしてこれは確実でしっかりした
規則ではありませんが),
<quote>make world</quote> の過程では,
基本的なツール ( &man.gcc.1;, や &man.make.1; のようなもの)
や, システムライブラリの新しいコピーが作成されます.
その後まず, これらのツールやライブラリはインストールされてから
自分自身の再構築に使われ, もう一度, インストールされます.
全体のシステム (ここでは &man.ls.1; や &man.grep.1; といった
標準的なユーザプログラムを含みます) は,
その新しいシステムファイルを用いて作り直されることになります.
</para>
<para>
もし, 再構築が最終段階に入っていること
が(記録しておいた出力を見たりすることで)わかっていたら,
(全く悪影響を与えることなく)次のようにすることができます,
</para>
<screen><emphasis>… fix the problem …</emphasis>
&prompt.root; <userinput>cd /usr/src</userinput>
&prompt.root; <userinput>make -DNOCLEAN all</userinput></screen>
<para>
これは, 前回の <quote>make world</quote>
の作業をやり直しません.
</para>
<para>次のメッセージ
<screen>--------------------------------------------------------------
Building everything..
--------------------------------------------------------------</screen>
が <quote>make world</quote> の出力にある場合には,
上のようにしてもほとんど悪影響が現れることはありません.
</para>
<para>
もしこのメッセージがないとか, よく分からないという場合には,
安全を確保し, 後悔するようなことがないよう,
システムの再構築を最初からやり直しましょう. </para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>あるマシンを <emphasis/マスタ/ として,
他の多くのマシンを (NFSで) アップグレードできますか?</para>
</question>
<answer>
<para>すべてのコンパイル作業をあるマシンで行ない,
構築されたものを他のマシンにネットワークを経由で
<command>make install</command>
することができるかどうかは,
よく FreeBSD メーリングリストで尋ねられます. </para>
<para>これはわたしが行った作業ではありませんので,
下に書かれている提案は, 他の人々から頂いたか,
Makefile から推論したものです.</para>
<para>取るべき適切な方法については,
利用している FreeBSD のバージョンに依存します.</para>
<para>
アップグレードしたマシンでは, この作業を行った後に
<filename>/etc</filename> や <filename>/dev</filename> の
更新を行わなくてはなりません.</para>
<para>2.1.7 とそれより古いものについて, Antonio Bemfica は
次に示すような方法を教えてくれました. </para>
<screen>Date: Thu, 20 Feb 1997 14:05:01 -0400 (AST)
From: Antonio Bemfica <bemfica@militzer.me.tuns.ca>
To: freebsd-questions@FreeBSD.org
Message-ID: <Pine.BSI.3.94.970220135725.245C-100000@militzer.me.tuns.ca>
Josef Karthauser は質問しました:
> どなたかネットワークを通してマシンをアップグレードするよい方法は知りませんか
まず, メインとなるマシンで make world などをします.
そして次のように, リモートのマシンから / や /usr をマウントします:
main_machine% mount remote_machine:/ /mnt
main_machine% mount remote_machine:/usr /mnt/usr
そして, /mnt をインストール先に指定して 'make install' とします:
main_machine% make install DESTDIR=/mnt
これをネットワーク上の他のマシンについても繰り返してください.
わたしの場合には, これでうまくいきました.
Antonio</screen>
<para>この仕組みは (わたしの知る限り) NFS サーバ上の
<filename>/usr/src</filename> が書き込み可能である場合にのみ
きちんと動作します. FreeBSD-2.1.7 とそれ以前では,
この作業に <maketarget>install</maketarget> ターゲットを使います.
</para>
<para>FreeBSD-2.1.7 と FreeBSD-2.2.0 の間で
<quote>reinstall</quote> ターゲットが導入されました.
上にあげた FreeBSD-2.1.7 向けの方法に加え,
<quote>install</quote> の代わりに <quote>reinstall</quote> を
使うことができます. </para>
<para>この方法では, NFS サーバ上の <filename>/usr/src</filename>
ディレクトリへの書き込み権限は必要
<emphasis>ありません</emphasis>.</para>
<para>Makefile の 1.68 から 1.107 の間のバージョンには,
このターゲットに関するバグがありました.
それは NFS サーバへの書き込み権限が
<emphasis>必要になる</emphasis> というもので,
このバグは FreeBSD-2.2.0 がリリースされる前に修正されました.
この時期の -STABLE が動いている古いサーバでは,
問題になるかも知れません. </para>
<para>FreeBSD-2.2.5 以降のバージョンでは,
<quote>buildworld</quote> と
<quote>installworld</quote> ターゲットが利用できます.
これらを使ってソースツリーを一つのマシンで構築し,
<filename>/usr/src</filename> と
<filename>/usr/obj</filename> をリモートマシンで
NFS マウントして, そこからインストールすることができます.</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>どのようにすれば make world を高速化できますか?</para>
<itemizedlist>
<listitem>
<para>シングルユーザモードで動かしてください.</para>
</listitem>
<listitem>
<para><filename>/usr/src</filename> と
<filename>/usr/obj</filename> ディレクトリを,
異なるディスク上の別のファイルシステムに置いてください.
また可能ならば, 異なるディスクコントローラに接続された
ディスクを使って下さい. </para>
</listitem>
<listitem>
<para>さらに高速化するには, これらのファイルシステムを
<quote>ccd</quote> (連結ディスクドライバ) デバイスを
使って, 別々なディスク上に置いてください.</para>
</listitem>
<listitem>
<para>プロファイル版の作成を無効化して下さい.
(<filename>/etc/make.conf</filename> で
<quote>NOPROFILE=true</quote> をセットします)
普通, それが必要になることはありません. </para>
</listitem>
<listitem>
<para>また, <filename>/etc/make.conf</filename> の中の
<quote>CFLAGS</quote> を,
<quote>-O -pipe</quote> のように指定しましょう.
<quote>-O2</quote> の最適化はさらに多くの時間を必要とし,
しかも <quote>-O</quote> と <quote>-O2</quote> の
最適化には, ほとんど差はありません.
<quote>-pipe</quote> を指定することで,
コンパイラはテンポラリファイルの代わりにパイプを利用します.
その結果, (メモリの利用は増えますが)ディスクアクセスが減ります.
</para>
</listitem>
<listitem>
<para>(もしあなたが十分に最近のバージョンの FreeBSD を使っているなら)
複数のプロセスを並列に実行させるため,
make に <option>-j<n></option> オプションを指定してください.
これはプロセッサが単一か複数かによらず,
どちらも同様に恩恵を得ることができます.</para>
</listitem>
<listitem><para><filename>/usr/src</filename> のある
ファイルシステムを, <quote>noatime</quote>
オプションを付けてマウント(もしくは再マウント)してください.
これは, そのファイルシステムにおいて,
最後にアクセスされた時刻の書き込みを抑制します.
おそらく, この情報が必要になることはないでしょう.</para>
<note>
<para><quote>noatime</quote> が利用可能なのは,
FreeBSD-2.2.0 以降です.</para>
</note>
<screen>&prompt.root; <userinput>mount -u -o noatime /usr/src</userinput></screen>
<warning>
<para>上の例は,
<filename>/usr/src</filename> 自身が独立したファイルシステムで
あることを想定しています.
もしそうでないときには (例えば <filename>/usr</filename> の
一部である場合には),
<filename>/usr/src</filename> ではなく
適切なマウントポイントを指定する必要があります.
</para>
</warning>
</listitem>
<listitem>
<para><filename>/usr/obj</filename> のあるファイルシステムを,
<quote>async</quote> オプションをつけてマウント (もしくは
再マウント) してください. これによって,
ディスクへの書き込みが非同期になります.
つまり, 書き込み命令はすぐに完了するのに対し,
実際にデータがディスクに書き込まれるのは, その数秒後になります.
これによって, 書き込み処理の一括化が可能になるため,
劇的なパフォーマンスの向上が期待できます.
<!-- hrs:2000/02/15 (for ja-translators)
"be clusterd togather" is translated into "clusterization" -->
</para>
<warning>
<para>
このオプションを指定すると, ファイルシステムは
壊れやすくなってしまうことに注意してください.
このオプションを付けていて, 突然電源が落ちた場合には,
再起動後にファイルシステムが復旧不能になる可能性が
非常に高くなります. </para>
<para>もし, <filename>/usr/obj</filename> 自身が独立した
ファイルシステムであるならば, これは問題になりません.
しかし, 同じファイルシステムに, 他の貴重なデータを置いているときには,
このオプションを有効にする前に,
バックアップをきちんと取っておきましょう.</para>
</warning>
<screen>&prompt.root; <userinput>mount -u -o async /usr/obj</userinput></screen>
<warning>
<para>もし <filename>/usr/obj</filename> 自身が
ファイルシステムでない場合には, 適切なマウントポイントを指すように,
上の例の名前を置き換えて下さい. </para>
</warning>
</listitem>
</itemizedlist>
</question>
</qandaentry>
</qandaset>
</sect2>
</sect1>
</chapter>
<!--
Local Variables:
mode: sgml
sgml-declaration: "../chapter.decl"
sgml-indent-data: t
sgml-omittag: nil
sgml-always-quote-attributes: t
sgml-parent-document: ("../book.sgml" "part" "chapter")
End:
-->