Debianはしばらく、libcとして、glibcではなく、glibcと互換性を維持したforkであるeblicを使っていたが、このたび、glibcに戻る決定をしたそうだ。
glibcを使っていた理由はいろいろあるが、Debianにとって重要なパッチが、glibcでは開発体制の問題により受け入れられないという政治的な理由もあったそうだ。その問題が解決されたのと、eglibcがプロジェクトとして死んだので、戻るのだそうだ。
Debian is switching (back) to GLIBC | Aurelien's weblog
5年前、Debianと多くの派生ディストロは、標準であるGNU C Library (GLIBC)から、Embedded GLIBC (EGLIBC)に乗り換えた。Debianは、GLIBCに再び乗り換えることにする。EGLIBCの最後のリリースは2.19と、プロジェクトとして死んでいるからだ。現時点で、glibcパッケージがexperimentalにアップロードされ、 NEW queueにある。
EGLIBCが死んだのは、物事が良い方向に変わってきたからだ。GLIBCの開発体制は、ここ数年で、二つの大きな事件により、大きく変わった。Ulrich DrepperがRed Hatを辞めて、GLIBC開発から手をひいたのと、GLIBC steering committeが自然消失したからだ。この結果、協力的なチームワークによる友好的な開発体制に変わった。開発は今やピアレビューを基本とし、結果として不具合が減少した(人間は誤りを犯すものである)。昔ならば不可能であったことも可能になった、例えば、すべてのアーキテクチャで、同じレポジトリを使うとか、
ports/
ディレクトリを廃止するとかだ。かつては、二つのアーキテクチャー群に分かれていた。x86とかSuperHとかSPARCなどの主要アーキテクチャーは、主要レポジトリであるglibcレポジトリで、ARMとかMPSなどのアーキテクチャーは、副レポジトリであるglibc-portsレポジトリでサポートされていた。明らかに、分離には明確な理由はなく、変更が副レポジトリに適用され忘れることも多かった。それから、定期的な修正が行われる、本物の安定ブランチもできた。ほとんどの重要なEGLIBCの機能はGLIBCにマージされた。例えばbashではなくPOSIXシェルを使うとか、予約語を変えるとかだ。まだマージされていないのは、設定可能なコンポーネントだ。これは、 Debian-インストーラーで使う予定で、NISとk PRCをサポートせず、-Osを使った軽量版を作るとかだ。結局、そういう開発はしなかったし、Debianの対象となるハードウェアは、GLIBCのサイズより早く発展していったので、それほどの損失ではない。最終的に、EGLIBCのツリーから取り込まれなかったパッチは、5個だ。
- Installation of *_pic.a files for use of mklibs in debian-installer
- Dynamic reload of /etc/resolv.conf
- Installation of headers during bootstrapping
- Workarounds for PowerPC 8xx CPUs
- Access to FPSCR on SH4
パッケージ名は変更されない(ソースパッケージとソースを含むバイナリパッケージは除く)ので、ユーザーからは変更は意識されない。
EGLIBCのために働いてくれたCodeSourcery社員と、EGLIBCの主要な変更をGLIBCにマージするために多大な時間を割いてくれた上に、マージ状態に関するメールを定期的に送ってくれた、Joseph Myers感謝する。そして、GLIBCの改革を実現してくれたGLIBC側の人々と、GLIBC開発に関わったすべての人々に感謝する。
ちなみに、Red Hatを辞めたUlrich Drepperは、ゴールドマン・サックスに移ったのだが、Reddit上では、これは2008年の経済問題を引き起こした張本人を罰するために移ったのだというジョークが書かれている。
Debian is switching back to GLIBC | Hacker News
結局、独裁者の存在は、長期的に見れば損失が大きい。
最後のまとめの一文のまとめにはみんな「Linusは…?」って思うぞ。
ReplyDelete