NetBSD には Formal Release, current と呼ばれる 2つのバージョン(?)が存在します。
前者はある時点でもっとも安定していると 考えられているもので開発環境にはこちらを使うことが 勧められています。このシリーズのバージョン番号は 1.0, 1.1, 1.2 の様に 数字のみから構成されます。Formal Release に official patch(es) が 出た場合には 1.2.1 の様にもう一桁ふえる規則になっているようです。 しかしながら NetBSD の特徴の一つに
ということがあるので、結構時代遅れになったりしてしまいます。機能が 他の PC-Unix に比べて見劣りしたり、新しく発見された security hole が 開いたままだったりしてしまうわけです。
一方 current は毎日毎日ある時刻までに commit された source tree から 作られるもので compile できるかどうかも保証されていない物です。 ただし、こちらは毎日更新されているので(上手く動けば)機能的に Formal Release よりも優れていますし、新しい security hole も fix されている場合が多いです。このシリーズのバージョン番号は 1.2A, 1.2B の様に Last Formal Release のバージョン番号 + Alphabet に なっています。(もっとも、このバージョン番号が同じであっても中身が 全然違ったりするのできちんと指定するには何月何日のこのバージョン みたいにしないとわからなかったりするんですけど)
で、この current を追っかけるときの注意点をまとめようというのが ここでの目的です。
たまぁに snapshot という名目で ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-current/arch/ 以下に compile 済の tar.gz がある場合もありますが、NetBSD-current は基本的にはソースでしか手に入りません。 したがって、取りあえず NetBSD が動く環境を作らないといけません。さらに、自分で compile する以上 source tree と object files が入るだけの disk space が 必要です。いまのところ、大体 source tree に 330MB、 i386 port の場合 object files に 140MB ってとこです。
以上の準備が終れば source tree を取りにいきます。最初は ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-current/tar_files/src/ 以下に tar.gz 形式でおかれているソース群を取ってきます。これらを /usr/src/xxxx という形式になるように展開します。リリースサイクル以外の時は tar.gz ファイルは一週間に一度しか更新されていないのでその時点の最新の source tree にしたい場合はsup(8)を使ってさらに更新します。 日本で NetBSD の sup service をやっているのは(最近 news を読んでないので おっそろしく古い情報ですが) ftp.sra.co.jpと ftpsv1.u-aizu.ac.jp だとおもいます。他にあれば教えてください。 ちなみにこのマシンでもサービスを行っています。詳しくは README_SUP.tackを 見てください。SUP は Software Upgrade Protocol という名前のとおり 更新されたファイルだけを取ってくるので全体を取ってくるより Network にかける 負荷が小さくなります。
ちなみに、どの sources が更新されるかは sup に -f
オプションを
与えてやればわかりますし、
current-usersに
毎日の更新情報が "daily CVS update output" という subject で流れてきます。
各 source が更新された理由までしりたい信者の方は
source-changes
を取ればわかります。
まずは current-usersを subscribe してください。で、FYI: とか README とかいう subject でやってくる mail を きちんと読まないと絶対はまります。一般に formal release が出てから 時間がたちすぎていると入れ換えというのはものすごく困難になります。つまり、 いったん current を追っかけ始めると定期的に追っかけないとにっちもさっちも いかなくなるのでまずは覚悟を決めましょう。
追っかけるといってもやることというのは /usr/src ディレクトリに
移って make build
とうつだけです。(上手くいけばね)
その時の注意点は
ことでしょうか。私は 2台目のハードディスクの a partition に formal release の NetBSD をいれてどうしようもなくなることに対応しています。
さらに私がきづいた bug などに対応するためのTERA.patches なども 参考になるかもしれません。TERA.patches を あてておくと build で作り直すあいだは multi user mode でも構わないです。
ちなみに、作り直して新しくするのには大体 てらで 5時間程度かかります。
「時々」ならあります。ある場合は、 ftp://ftp.jp.netbsd.org/pub/NetBSD/NetBSD-current/arch/ や ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-current/arch/ の下に見つけることができます。
また i386 ならば、私が current を更新した場合に、make snapshot した結果を ftp://tack.fukui-med.ac.jp/pub/NetBSD/arch/i386/snapshot/ に置いているので使えるかもしれません。yyyymmdd という subdirectory の下に あります。ただしここにあるものには TERA.patches があたっており、素の current ではありません。
disk が充分にあるのならば cvs
を使えばお気軽に更新できます。
始めてやるときに
% cvs -d CVSROOT import -m "import NetBSD /etc directory as of date" NetBSD/etc NetBSD As_of_srcdateとしてまずは NetBSD 配布の etc を cvs の管理下につっこむ。CVSROOT には cvs の repository の root を入れてください。初めて
cvs
を
使う場合には
cvs -d CVSROOT initが必要かも知れません。
% cvs -d CVSROOT co NetBSD/etcとして取り出す。
% rm spwd.db pwd.db passwd fstab.sd fstab.wd % cvs rm spwd.db pwd.db passwd fstab.sd fstab.wd % echo spwd.db pwd.db passwd fstab.sd fstab.wd > .cvsignore % cvs add .cvsignore % cd mail % rm aliases.db % cvs rm aliases.db % echo aliases.db > .cvsignore % cvs add .cvsignore % cd .. % cvs commit -m "remove auto generated files"
mv /etc /etc.old; cp -pr NetBSD/etc /etc
として
/etc を入れ替える。
cvs commit
する。
次からは cvs import
までは同じですが、ここで、 conflict が
多分出るので、最後に出る message の通りに
cvs -d CVSROOT checkout -jNetBSD:yesterday -jNetBSD NetBSD/etcとして、merge してやると、「大部分」の変更は取り込まれます。残った conflicts は「少ない」ので、手で直してもそんなには大変じゃありません。
うまくいけば、make build
とうてばいいということは、
逆にいうと上手くいかないときがあるってことです。バグを見つけて
fix したならば、他の人たちが幸せになれるように
send-pr
しましょう。その時に気をつけることは....