2008年11月23日日曜日

rpmlint

このエントリーをブックマークに追加 このエントリーを含むはてなブックマーク
rpmのspec fileのparserを書いていて、ふと気になったので、テストケースに使っているspec fileをrpmlintにかけてみた。linux kernelですら文句を言われるようだ。ほかのpackageのspec fileはおして知るべし。

gitage/rpmspec/testdata/kernel.spec:10: W: hardcoded-path-in-buildroot-tag /var/tmp/%{name}-%{PACKAGE_VERSION}-root
gitage/rpmspec/testdata/kernel.spec:11: W: unversioned-explicit-provides kernel-2.6.27.5
gitage/rpmspec/testdata/kernel.spec: E: no-cleaning-of-buildroot %install
gitage/rpmspec/testdata/kernel.spec: E: no-cleaning-of-buildroot %clean


rpmlintの
一部
。うげー。プログラムというより、データだなこりゃ。check関係のfileはひとつのdirにまとめてpackageにすればいいのに。どうせcheckの内容が対象ごとに書いてあって、fileごとに対象が決まっているとかいうつくりでしょ?ならliblint/とかrules/とかpulgin/とlibcheck/かかにしておけばいいのに。名前空間使え~。

rpmlintはスクリプトからの起動時の起点。
SpeckCheck.pyはすさまじいif文のあらし。こんなコード読みたくない。
lintを書こうとすること自体の発想が力技でバッドノウハウに喧嘩売る行為なので、そういう発想のもとにコードを書けば必然なのかもしれない。

おいらだったらif文の代わりにinstance methodかなんかにして、

437 'no-spec-file',
438 '''No spec file was specified in your RPM building. Please specify a valid
439 SPEC file to build a valid RPM package.''',

みたいな部分はmethodのdocumentにするとか、
検出するためのregexpとhandlerとoutputにするtextが一箇所に集中していないのは読み手に優しくないなぁ。もしくは
regexp_xxx/handle_xxx/document_xxxみたいなconventionを採用するとか。
reportのi18nとかもどうするんだか。

0 件のコメント: