Table of Contents
GNOME の web サイトによれば、
GNOME プロジェクトでは二つのものを提供します: 一つは、 利用者にとって直観的で魅力的なデスクトップである GNOME デスクトップ環境です。 もう一つは、アプリケーション構築用の広範な枠組である GNOME 開発プラットフォームで、その他のデスクトップに統合されています。
pkgsrc を使うと、多くのプラットフォームのもとで、 完全な GNOME 環境の自動的な構築やインストールを透過的におこなうことができます。 pkgsrc は、buildlink3 技術、ラッパーとツールの枠組や、 設定ファイルの自動処理があることから、 GNOME の構築およびパッケージングシステムとして最も高度なもののひとつであると、 自信を持っていうことができます。 インストールされたソフトウェアの構成要素を、 完全にきれいにアンインストールできるようにするため、 多くの取り組みがおこなわれています。
pkgsrc は NetBSD の公式パッケージングシステムなので、 上述したことはすなわち、NetBSD のもとで GNOME が機能するようにするために、 多大な取り込みがおこなわれているということです。最近では、DragonFly BSD も pkgsrc をパッケージングシステムとして採用しており、 同 OS のもとで GNOME の構築やインストールができるようにするため、 移植性に関する修正を数多く寄せてくれています。
あなたの空き時間を NetBSD のために使っていただけたら、 pkgsrc および GNOME は、おもしろげな新機能の導入に注力することができます。まずは保留中の作業 の一覧をご覧ください。NetBSD のもとで GNOME デスクトップを完全に機能させるまでには、まだ長い道が残っているため、 あなたの助けが必要なのです。
pkgsrc には、GNOME 関連のメタパッケージが三つあります。
meta-pkgs/gnome-base: GNOME
デスクトップ環境の中核部分を提供します。
これは GNOME を正常に起動させるために必要なものだけからなっており、
日々の操作をするうえで重要な機能が足りないかもしれません。
このパッケージの考え方は、
末端利用者がこのパッケージの上層で独自の構成をできるようにするためのものであり、
このメタパッケージをまずインストールして最低限の機能を整えてから、
個々のアプリケーションを追加するというものです。
meta-pkgs/gnome: GNOME
プロジェクトが定義する GNOME プラットフォームおよびデスクトップの、
完全なインストールを提供します。これは、GNOME の公式 FTP サーバーの
platform/x.y/x.y.z/sources および
desktop/x.y/x.y.z/sources
ディレクトリーで配布されている構成要素にもとづいています。
このディレクトリーにある開発者専用ツールは、他の構成要素の正常動作のために必要な場合以外は、
インストールされません。同様に、バインディングセット附属のパッケージ
(bindings/x.y/x.y.z/sources)
も、末端利用者向けの構成要素からの依存により必要な場合以外は、
含まれません。このパッケージは、meta-pkgs/gnome-base を「拡張」するものです。
meta-pkgs/gnome-devel:
GNOME の構成要素を CVS リポジトリーから取得した場合用に、
その構築のために必要なツールをすべてインストールします。
これらは
autogen.sh スクリプトを正常に動かすために必要なものです。
以上の各パッケージでは、更新を簡単にできるようにするため、
DEPENDS 行が依存性にもとづく順序で並べられています。
あるパッケージが、それより前に並んでいるパッケージに依存することはできますが、
後に並んでいるパッケージに依存することはできません。この順序を守ることは、
更新を簡単にするために非常に重要なことです。これを、
アルファベット順に並びかえてはいけません。
ほとんどすべての GNOME アプリケーションは C で書かれており、 構築システムとして共通のツール一式を使っています。C 以外の言語 (Python など) を新たに追加する場合は事情が異なりますが、 最低限必要なツールについては、以下のことが参考になるでしょう。
ほとんどすべての GNOME アプリケーションは、構築システムとして GNU Autotool を使っています。GNOME に限らない一般的な決めごととして、 このことをパッケージに教えてやる必要があります。
GNU_CONFIGURE=yes USE_LIBTOOL=yes USE_TOOLS+=gmake
パッケージが pkg-config を使って依存性を決めている場合は、 必要なユーティリティーのリストに同ツールを追加します。
USE_TOOLS+=pkg-config
さらに、構築の過程の最後で
pkgtools/verifypc を使って、
作ったパッケージのなかで指定した依存性に間違いがなく、
要求バージョンもすべて正しいことを確認します。
パッケージが intltool を使う場合は、依存性を処理するため、また、
利用可能な最新バージョンを使うようにするため、かならず
intltool を USE_TOOLS
に追加します。
パッケージが gtk-doc (ドキュメンテーション生成ユーティリティー) を使う場合は、依存性を追加してはいけません。 このツールは巨大なものですし、 パッケージの distfile には生成済みのドキュメンテーションが附属しているはずだからです (そうなっていない場合はバグですので、報告してください)。 このようなパッケージでは、以下のようにして gtk-doc を無効化するようにします (標準で無効になっている場合を除く)。
CONFIGURE_ARGS+=--disable-gtk-doc
HTML ファイルの標準でのインストール場所
(share/gtk-doc/<package-name>) は適切なものなので、
パッケージが別の場所へのインストールを要求した場合以外は変更しないようにします。
場所を変更すると、devhelp
などのプログラムがファイルを開けなくなってしまいます。
場所の変更は、以下のようにしておこなうことができます。
CONFIGURE_ARGS+=--with-html-dir=${PREFIX}/share/gtk-doc/...
GNOME は、インストール用プレフィックスの下に複数の
共有ディレクトリーおよびファイルをもっており、
データベースの保守のために使っています。ここでいう共有とは、
同じディレクトリーやファイルを複数の異なるパッケージが使うことであり、
PLIST の内容の衝突を起こします。
現在、pkgsrc にはもっともありがちな部類の事例を扱うための仕組みがあるので、
ファイルのリストには必ず
@unexec ${RMDIR} という行を書くようにし、
共有のファイルは書かないようにしてください。
この仕組みを使わずに独自の処理をしてしまうと、
作成したパッケージが、正しくないものになってしまうでしょう。
以下の表は、共有ディレクトリーまたはファイルを使うような、 ありがちな状況を挙げたものです。各状況について、適切な処置を示しています。 ここで示した処置を適用した後は、 make print-PLIST を使って パッケージのファイルのリストを作り直し、 それが正しいことを確認してください。
Table 23.1. GNOME パッケージ用の PLIST の扱い
| パッケージの挙動 | 処置 |
|---|---|
share/omf 以下に OMF ファイルをインストールする。 |
Section 19.6.10, “scrollkeeper/rarian のデータファイルをインストールするパッケージ”参照。 |
share/icons/hicolor
階層以下にアイコンをインストールする、または
share/icons/hicolor/icon-theme.cache を更新する。 |
Section 19.6.19, “ハイカラーテーマのアイコンをインストールするパッケージ”参照。 |
share/mime/packages
以下にファイルをインストールする。 |
Section 19.6.14, “MIME データベースの拡張をインストールするパッケージ”参照。 |
share/applications 以下に
.desktop ファイルをインストールし、かつそのファイルに MIME
情報が含まれる。 |
Section 19.6.20, “デスクトップファイルをインストールするパッケージ”参照。 |
GNOME を全体として見た場合、 二種類の更新があります。
GNOME 3 (がいつか登場したとして) への道程は、まだ相当長いものなので、
ここでは、バージョンが 2.X から 2.Y
(Y は X より大きい偶数)
に上がることをメジャーアップデートということにします。
メジャーアップデートでは構成要素のコードに多くの変更がおこなわれており、
GNOME のほとんどすべての distfile が新しいバージョンに更新されているため、
更新は面倒な作業になります。変更のなかには、
以前のバージョン系列との API や ABI の互換性を損なうものがあることもあります。
このような事情があるので、破損を最小限にするために、
更新は一度にまとめておこなう必要があります。
通常、メジャーアップデートでは、 約 80 個のパッケージが更新されるほか、新しいパッケージがいくつか追加されます。
ここでは、バージョンが 2.A.X から 2.A.Y
(Y は X より大きい数)
に上がることをマイナーアップデートということにします。
GNOME の構成要素すべてが更新されるわけではないことや、
枝内でのバージョン増大に沿った形でおこなうことができ、
API や ABI の互換性が失われないことなどから、
更新は簡単におこなうことができます。
マイナーアップデートで更新されるパッケージ数は、 大きく変動することがありますが、通常は約 50 個です。
pkgsrc の GNOME 構成要素を新しい安定版リリース (メジャーまたはマイナー) に更新するためには、 以下の手順に沿っておこなうようにします。
以下のコマンドを使って、新しいリリースを構成する tarball
の一覧を作ります。
こうすると、構成要素の distfile の全一覧が
list.txt ファイルに得られます。
%echo ls "*.tar.bz2" | \ ftp -V ftp://ftp.gnome.org/pub/gnome/platform/x.y/x.y.z/sources/ | \ awk '{ print $9 }' >list.txt%echo ls "*.tar.bz2" | \ ftp -V ftp://ftp.gnome.org/pub/gnome/desktop/x.y/x.y.z/sources/ | \ awk '{ print $9 }' >>list.txt
各メタパッケージの Makefile を開き、
バージョンを更新後のリリースのものに上げます。
3 個のメタパッケージは常にバージョンに整合性をもたせるようにします。
PKGREVISION がある場合は、
当然、削除します。
各メタパッケージについて、
DEPENDS 行を更新して、
前掲のコマンドで得られた最新バージョンと合致するようにします。
これより新しいバージョンにしては (たとえそれが FTP サーバーにあったとしても)
いけません。このメタパッケージは、
特定の GNOME リリースを構成するバージョンだけを揃えることを意図したものだからです。
ただし、統合デスクトップを使用する上での深刻な問題が新しいバージョンで解決する場合には、
例外的に認められます。これは、たいていの場合、
GNOME による新しいバージョンは使わずに、
pkgsrc 内でのリビジョンを上げる形をとります。
list.txt ファイルに現れないパッケージは、
利用可能な最新バージョンに (pkgsrc にそれがあれば) アップデートするようにします。
たとえば、meta-pkgs/gnome-devel メタパッケージに含まれるパッケージのうち
GNU Autotools に依存するパッケージがこれに該当します。
変更後のメタパッケージからパッチを作り、そこから「新規の」行を抽出します。 この結果から、pkgsrc のどのパッケージをどの順序でアップデートする必要があるか、 概要がわかります。
%cvs diff -u gnome-devel gnome-base gnome | grep '^+D' >todo.txt
デスクトップのメジャーアップデートの場合は、 インストールされているパッケージをすべて削除し、まっさらな状態から始めることをおすすめします。
ここが、もっとも長い作業が必要なところです。
todo.txt に書き出された各パッケージを、
並んでいる順序どおりに更新するという作業を繰り返します。
デスクトップのメジャーアップデートの場合は、
全パッケージの更新が完了するまで commit してはいけません。
未更新のパッケージを壊す可能性があるからです。
パッケージが新しいものになり動作する状態になったら、
個々のパッケージを一つずつ、適切な log メッセージをつけて commit してゆきます。
最後に、3 個のメタパッケージの更新と、これらに対応する
doc/CHANGES-<YEAR> および
pkgsrc/doc/TODO ファイルの変更を
commit します。
GNOME は 100 のパッケージを擁する、pkgsrc の大きな構成要素です。 GNOME パッケージに移植性に関する修正を施した場合は、常に、常に、 常に、 GNOME 本家の開発者に還元していただくということが重要です (Section 11.3.5, “作者へのフィードバック”参照)。 彼らに移植性についての注意を喚起して、将来のバージョンが無修正で NetBSD で構築できるようにするためには、そうするしかないのです。 pkgsrc 独自のパッチを少なくすればするほど、将来の更新は楽になります。 GNOME のメジャーアップデート対応に取り組む開発者としては、 皆さんにそのようにしていただけるとありがたく思います。
最もありふれたバグの報告先は、GNOME の Bugzilla と freedesktop.org の Bugzilla です。GNOME の構成要素すべてがこれらをバグ追跡用に使っているわけではありませんが、 ほとんどはこれらを使っています。バグ報告に際しては、常に、 現在起きている問題や、移植性を最大限にするためにはどのように改良したらよいかについて、 詳細に説明するようにし、また、可能であれば CVS の head に対するパッチをつけてください。 詳しく書けば書くほど、パッチが採用される可能性が高くなります。
また、プリプロセッサーを使った細工で移植性の問題を修正するようなことはしないでください。
FreeBSD で GNOME に取り組む人たちは、彼らのオペレーティングシステムへの GNOME の移植にあたり大きな仕事をしていますが、
このせいで、公式の GNOME のソースに __FreeBSD__
や、これと同類のマクロの検査が蔓延してしまっています。これは移植性を損なうものです。
詳細は、私たちのパッチ作成の指針
(Section 11.3.4, “パッチ作成の指針”)
をご覧ください。