Gentoo のパッケージの設計図に当たるものは ebuild というシェルスクリプトで記述されているのだが、似たような ebuild を書くときに、大元の ebuildをコピーして別々に管理したりしていると、複数のバージョンをメンテナンスするのも大変なので、そういうときは共通部分を eclass という別のシェルスクリプトに分けて書き、各 ebuild では違う部分だけ書けばよい、というように作業を省略することができる。また、便利な関数を集めた eclass を書いておけば、それを使いたい ebuild はその eclass を取り込むだけでいちいち関数を定義しないで使えるので便利。
まあ各々別のパッケージシステムでも似たようなことはできるので、別にこれはGentoo の専売特許というほどのものでもないが……。
しかし共通部分を追い出すタイプの eclass だと、nakano さんが常々指摘しているように、eclass にもバージョンがないと不便かも。あるバグの fix をするとき、確かに eclass を使わないで ebuild をメンテナンスすると、それぞれの ebuildに同じような変更を全部加えないといけないので面倒なのだが、eclass に手を入れるとなると変更は1回でよいものの、eclass にバージョンがないために、問題の fixが入ったものであることを Portage が検出することができない(のでアップグレードの対象にならない)。
とりあえずの回避策としては、eclass にバグの解決策が入った場合にユーザにアップグレードさせたいとき、ebuild は全く同一であるが、バージョン番号だけ変えたものを用意する、という方法が取られているようだ。こうすると内容は同一だが、アップグレードする際には新しい eclass が使われるため、バグの対応策が取り込まれた状態でビルドされると。しかしなんかいまいち。本来なら eclassにもバージョンをつけ、新しい ebuild では問題の fix が入ったバージョンのeclass に依存する、というようにするべきだろう(結果は同じになるけど)。
nakano さんの話によると、(過去から)現在まで Portage を精力的にメンテナンスしている人と eclass を実装した人が違うので、eclass は開発の立場からはあまり歓迎されてないようなのだが、eclass を使うと ebuild を書く人はかなり楽できるので、最近 eclass の数がやたらめったら増えていたりする。eclass を使ったebuild はビルド・インストールプロセスが隠蔽されてしまったりするのであまりよくないと思う面もあるが……
