hogeとはワイルドカードのようなものです。日々起こった、さまざまなこと −すなわちワイルドカード− を取り上げて日記を書く、という意味で名付けたのかというとそうでもありません。適当に決めたらこんな理由が浮かんできました。
01/23/2004 ねむ [長年日記]
■ [Gentoo] あら？
emerge --usepkg hogehoge
とかやると，KEYWORDS が ~x86 だろうがなんだろうが PKGDIR に存在する hogehoge パッケージの最新をインストールしてしまう模様．--usepkg の場合って ebuild 見ないのか？ だとしたら恐くて BINHOST を迂闊に設定して emerge -gK なんて，stable 環境じゃできんぞ…．
…と思って emerge をちらっと読んでみたら binary と ebuild できっぱり分かれてるみたいね．うーん，これは嬉しくないなあ．
つか，emerge の 903 行目，
if portage.pkgcmp(myeb_s, myeb_pkg_s) > 0: # eb is newer than pkg
myeb_pkg = None
else:
myeb = None
が悪さしてんじゃん．
- myeb は Portage ツリーにある，KEYWORDS や MASK を考慮した最新の ebuild
- つまり myeb より新しいバージョンは unstable or masked
- myeb_pkg は KEYWORDS や MASK を無視した最新のバイナリパッケージ
- myeb_pkg が myeb よりも新しかったとしても，myeb_pkg をインストールするのはおかしい
ということから，この部分を
if portage.pkgcmp(myeb_s, myeb_pkg_s) > 0: # eb is newer than pkg
myeb_pkg = None
else:
myeb_pkg = myeb
myeb = None
とすると良いと思うんだがどうか．else 以下に一行加えただけだけど．
まぁバイナリパッケージもちゃんと KEYWORDS を理解してくれるようになる (binarytree.dep_bestmatch() を改造する) のがベストなんだけど．
と思って Bugs 探索をしてみると，似たようなのが bug#26314 にあった．これパッチ作って投稿してみよかな？ たった一行だけど．
■ [Gentoo] うひゃ
確かにその通りでした． しかも --usepkgonly の場合に対処できてませんでした．いつもながらの思慮不足…．
…ので，修正してパッチにしてみました． --usepkgonly の場合を考慮するとちょっと日記に書くには量が多かったので…．
あ，ちなみに portage-2.0.49-r21 向けのパッチですが，2.0.50_pre16 でも行番号が違うだけでコードは一緒っぽいので適当に差し替えるだけだと思います．
つか，--usepkgonly だと myeb が None になっちゃってるからめんどくさい．やっぱ binarytree.dep_bestmatch() が KEYWORDS や MASK を見てくれると楽っていうかそもそもこんなことしなくて済むんだけど．
それだと、myeb<myeb_pkgのときに、存在しない（可能性のある）バイナリパッケージをインストールしに行ってしまいません？
そうですねぇ。バージョン番号だけでは判断できないですからねぇ・・。bestmatchを変えてもいいのですが、それも結構大変なんですよね。バイナリがリモートにある場合どうやって情報を取得するか・・など。全部ダウンロードするわけにはいかないですし・・。いい解決方法あったら教えてください。そのパッチもbugsにあげてもらえれば検討します（今は見ている余裕がないので、忘れてしまうかもしれないので）
うーん，bestmatch の方も今回僕が使った方法 (portage.portdb.xmatch("bestmatch-visible",pkg) で得られる Portage ツリーの最新バージョンと比較するなど) を使えばなんとかなるかも…？
リモートのも考慮するとなると getbinpkg.py もいじらなきゃならなくなるかもしれないですが．
それと binarytree から portagetree を参照できる必要がありますね．
あ，パッチはいつものヘタレ英語と共に投稿しておきました．