たとえば Bug 532188 – app-i18n/ibus-anthy should depend on dev-python/pygobject といったバグがあるのだけれど、こういうバグはなかなかやっかいで、手元でテストするともともと dev-python/pygobject が他からの依存で入っているためにうまく再現できなかったりする。
しかも、このバグの場合コメントにあるように
Given the deptree, this can only happen if you didn't set gtk3 useflag on ibus.
gtk3 の USEフラグ次第で結果が変わってしまいそうだ。
クリーンな環境でテストすると言うとまず VM が思いうかぶ。だが、そのVMもテストによって「クリーン」ではなくなる。初期の stage3 でスナップショットをとっておいて戻すという方法もあるが、 stage3 内のパッケージや Portage ツリーを更新するという必要もでてくる。しかも、 Gentoo だしなにかのパッケージをテストするためにフルスクラッチでコンパイルが走ったりして時間がかかってマジかよという状態になる。
まとめるとクリーンにテストして、 Gentoo の依存関係のバグを再現可能にするには、以下の性質を満たしてほしい
- stage3 は最新 (毎週更新される)
- Portage ツリーは最新 (毎日更新される)
- 一度ビルドしたパッケージはなるべくビルドしたくない
- でも、パッケージにUSEフラグの設定とかはしたい
こんなのを VM でポータブルに作ろうとするとめっちゃ大変そうなのだが、 Docker を使って実現できた。 最近は手元でこれを使って、おおたしかにこのUSEだと通るけど、こっちだと通らんわーとか再現するのに使って捗っている。
たとえば冒頭のバグだと
$ ~/repo/dockergentoo/bin/build-package.sh 'gtk+ +X' ibus-anthy
(ビルドが走って通る)
$ ~/repo/dockergentoo/bin/build-package.sh 'gtk+ +X ibus -gtk3 +deprecated' ibus-anthy
(ビルドがこける)
The result put into result/15014
となって、 ibusのUSEフラグが"-gtk3 +deprecated" だと ibus-anthy がこけるんだなあということがわかる。しかも、 ~/repo/dockergentoo/result/15014 の下に portage.tar.xz というファイルができていて、ここに /var/tmp/portage が圧縮されて入っている。
USE編集する以外にも、自分の書いた ebuild をoverlayとしてつっこめたりべんりな機能があるので活用してほしいところ。詳しくはスライドやGitHubを参考に。
世の中にはいっぱいバグがあるので、将来的にはジョブキューイングとかしてビルド結果が出たらぴょこんと通知が出る -> 新たなUSEでジョブ投入してコーヒーを飲むという感じでバグ処理のいらん手間を省けるやつも作っていきたい。
