MacPortsが通った道とHomebrew

Homebrewは、パッケージ管理システムというより、みんなのビルドノウハウをgithubを通して共有するシステムに見える。MacというシステムはLinuxのディストリビューション並に規格が定まっているので、結果の再現が可能で、失敗や成功を共有することが出来る、という状況の応用の1つとしてHomebrewが生まれたのだろう。

MacPortsはMacにデフォルトで入っている環境を見ず、自給自足とも言える仕組みを採用しているが、かつてはデフォルト環境に依存する仕組みも取っていたらしい。それを辞めた理由として、Macのデフォルト環境は融通が利かない、ネイティブなパッケージ管理システムではないのでデフォルト環境に変更があった場合管理している多くのパッケージに変更が生じる、などが挙げられている。

Snow LeopardからLionに移行し、gccはgnuのものからllvmのものになった。igraphのbrew Formulaを見ると、fails_with_llvm "Segfault while compiling."とあり、Lionではビルドに失敗する。パッチや解決策はhttp://web.archiveorange.com/archive/v/yj6N4VBSrwkOaZ5VhQtwやigraph: added support for --universal by ntamas · Pull Request #7570 · Homebrew/legacy-homebrew · GitHubにあるが、Formulaとして反映されていない。こうして、環境の変化に対応しきれないノウハウが積み重なりズレが生じていき、仕組みが破綻してしまうことは望ましくない。

App Storeのデベロッパバージョンのようなものとして、ネイティブのパッケージ管理システムが提供されれば解決するのかもしれない。それぞれのパッケージはAppleによって管理されてもいいし、第3者によって提供されAppleの審査と管理を受けてもいい。Xcodeにそういう機能が提供されれば、開発はよりやり易くなるかもしれない。しかし、Appleはおそらくそういう仕組みを提供しないだろう。段々とシンプルになり、じわじわと囲い込むような流れを作っているAppleが、そんな、下の層の仕組みを提供するとは思えない。

Homebrewに移行はしたが、MacPortsも入れたままにしている。LaTeX環境についてはMacTeXがデファクトスタンダードになっているそうなので、今後の移行はまあ当分ないだろうが、HomebrewとMacPortsのどちらが優勢になるか、正解かはまだ正直分かっていない。