openSUSE:パッケージングチェック

移動先: 案内, 検索
パッケージングガイドライン


品質や一貫性を保持するため、パッケージの構築時に自動化されたチェック機構が動作し、一般的な作成時エラーやパッケージポリシーの施行などを実施します。

目次

概要

自動的に動作するパッケージングチェックには、下記の 3 種類の方式があります:

brp-check-suse
spec ファイル内の %install セクションの実行後、実際のバイナリパッケージを作成する前に rpmbuild が実行する、ビルドルートポリシースクリプトと呼ばれる仕組みです。これらはパッケージのビルドルート (BUILDROOT) に対してアクセス権を持ちます。これらはたとえば、マニュアルページの圧縮など、ビルドルート内に存在するファイルを修正する際に便利な仕組みです。
post-build-checks
root でビルドスクリプトによって実行される仕組みです。これらのスクリプトは仮想マシン内のインストールと、ビルドシステムのプロパティにアクセスすることができます。これらのスクリプトは、インストールや構築結果を修正することもできます。
rpmlint
非特権ユーザでビルドスクリプトによって実行されます。 rpmlint は 1 回で 1 つのパッケージをチェックします。パッケージ作成者は、パッケージの設定ファイルを利用することで、疑陽性 (誤った警告) を省略するようにすることもできます。

post-build-checks と brp-scripts について

これらのチェックは非常に柔軟な仕組みであるため、パッケージをチェックする際には rpmlint を利用することをお勧めします。また、可能であれば新しいチェックは rpmlint で作成するものとし、以前からあるチェックも rpmlint に移植することをお勧めします。下記に続くサブセクションでは、 rpmlint 以外のチェックで発生しうる問題について情報を提供しているほか、次の章では rpmlint に関する情報を提供しています。さらに詳しい情報 (場合によっては Fedora 固有のものもあります) については、 古い英語版の wiki をお読みください。

post-build-checks の無効化

BuildRequires:	-post-build-checks

rpath 問題

ソースコード側の作りによっては、ライブラリをリンクする際に固有のライブラリパスを指定 (-rpath または -R フラグ) して、それをハードコードするようになっているものがあります。これは rpath 問題として知られているもので、 Fedora では禁止されている仕組みです。通常、ダイナミックリンカとローダ (ld.so) が実行ファイルの共有ライブラリへの依存関係を解決し、何が必要であるのかを動的に判断します。しかしながら、 -rpath または -R を使用してしまうと、バイナリ内にライブラリの場所がハードコードされてしまい、実行の際の冒頭でそれを ld.so が読み込んでしまいます。

OBS では、 %install セクションの実行後に /usr/lib/rpm/brp-rpath (およびその他の brp-* スクリプト) を実行して、チェックを行ないます。 rpath のチェックを無効化したい場合は、 %install セクションの最後に 

export NO_BRP_CHECK_RPATH true

を追加してください。

brp-rpath を実行すると、下記のような出力を得ることができます: 

ERROR: RPATH "/usr/Mod/PartDesign" on /home/abuild/rpmbuild/BUILDROOT/freecad-0.13rc.svn5443-20.1.i386/usr/Mod/PartDesign/PartDesign.so is not allowed

なお、バイナリが非標準の場所 (標準は /lib, /usr/lib, /lib64, /usr/lib64 です) にあるライブラリを参照しようとする際にも、 rpath を利用して行ないます。お使いのパッケージでライブラリを非標準の場所 (たとえば /usr/lib/foo/ など) に保存しようとしている場合は、 /etc/ld.so.conf.d/ 内に独自の設定ファイルを配置し、パッケージに含めるようにしてください。たとえば /usr/lib/foo に 32 ビット版のライブラリを配置する場合、 /etc/ld.so.conf.d/ 内に "foo32.conf" のようなファイルを配置し、下記のとおり内容を記述してください: 

/usr/lib/foo

なお、このファイルは 64 ビット版に対しても作成する必要がある (例: foo64.conf) ことにも注意してください (もちろん 64 ビット版で構築しない場合は不要です) 。

rpath 問題の解決

rpath 問題を解決するには、下記などの方法があります:

  • アプリケーションが configure スクリプトを利用している場合は、 configure 時に --disable-rpath フラグを指定する。
  • アプリケーションが libtool のローカルコピーを利用している場合は、 spec ファイルの %configure 後の場所に、下記を挿入する:
%configure
sed -i 's|^hardcode_libdir_flag_spec=.*|hardcode_libdir_flag_spec=""|g' libtool
sed -i 's|^runpath_var=LD_RUN_PATH|runpath_var=DIE_RPATH_DIE|g' libtool
  • 場合によっては、 code/Makefiles を修正して -rpath や -R を利用しないようにすることもできます。ただし、この方法は簡単にはいかない場合があるほか、良識ある方法とは呼べません。
  • 最終手段としては、 openSUSE や Fedora で用意されている chrpath を利用する方法があります。このパッケージをインストールすると、 rpath 問題を含むファイルに対して、 chrpath --delete を実行することができるようになります。たとえば上述の例の場合、下記のように実行することができます:
chrpath --delete $RPM_BUILD_ROOT/usr/Mod/PartDesign

ただし、この方法を利用するには BuildRequires: chrpath を追加する必要があることに注意してください。

エラーを無視してパッケージを構築する方法

rpmlint が発生させるエラーについては、省略したり無効化したりすることができますが、 post-build-checks や brp-check-suse が発生させるものについては、省略や無効化を行なうことができません。これらのものが発するエラーをフィルタする方法はありません。また、適切な解決策が見つかるまでの一時的な回避としてのみ、エラーを無視するようにしてください。

rpmlint には 3 種類の結果があります。それぞれ information (情報), warning (警告), error (エラー) です。すべてのエラーが構築失敗を意味するほど致命的なものではありませんので、エラーによっては badness score (悪さのスコア) と呼ばれる値が割り当てられています。このスコアは 1 回の構築処理で合算され、一定の値を超えた場合にのみ構築を失敗として扱います。

rpmlint は常に正しい判断を下すというものではありませんので、特定のエラーメッセージを無視したり、 badness score を小さくして対応することができます。これらの設定にはパッケージ固有の設定ファイルを用意し、グローバルな設定値を上書きすることで実現します。

この仕組みを動作させるには、ソースコード内に %name-rpmlintrc と呼ばれるファイルを用意して、 spec ファイル内からそれを参照するようにします。

例: 

[...]
Source5:  perl-rpmlintrc
[...]

疑陽性 (誤った警告) の省略

この方法は 誤った 警告にのみ利用してください (警告に対して疑問がある場合は、メーリングリストにお問い合わせください) 。ディストリビューションのパッケージポリシー違反を無効化する方法については、次の章をお読みください。


addFilter コマンドを利用することで、正規表現でエラーメッセージをフィルタすることができます。 

addFilter("perl.* devel-file-in-non-devel-package")

上記の例は、 perl という名前の(サブ)パッケージに対して、 devel-file-in-non-devel-package という名前の警告をフィルタリングするための指定です。一般的にはできる限りフィルタリングの範囲を明示的に指定するものとし、必要な場合にのみ正規表現を利用してください。また、特定のファイルに対して警告をフィルタリングするには、下記のように記述します: 

addFilter("spurious-executable-perm .*/usr/share/doc/packages/cups/PrintAnalyzer")

一般的には、フィルタリングの指定には Perl/Python 形式の任意の正規表現を利用することができます。また、フィルタリングは rpmlint が出力するテキストに対して、直接マッチング処理を実施することに注意してください。

なお、この省略指定を行なうファイルはバイナリパッケージには含みません。出力された rpm に対して手作業で rpmlint を実行すると、省略された警告を表示させることができます。これは意図的にそのようにしているもので、何か一般的に削除されるべき rpmlint の警告があるとお考えの場合は、バグとして報告してください。

セキュリティポリシー違反など特定のエラーについては、 openSUSE Factory 内のパッケージでのフィルタリングは許可されていません。


致命的エラーの無効化

セキュリティチェックなどの項目には高い badness score が割り当てられていて、それだけのエラーで構築が失敗するようになっています。 openSUSE に取り込むことを想定していないパッケージでは、そのような致命的なエラーを警告に置き換えたい場合があります。これを行なうには、 'setBadness' コマンドを利用します。

たとえば、許可されていないパーミッションのファイルが含まれているようなパッケージを構築したい場合は、下記のように記述します: 

setBadness('permissions-unauthorized-file', 0)


openSUSE における rpmlint のチェック

arch-dependent-file-in-usr-share

このパッケージは /usr/share 以下に ELF 形式のバイナリをインストールしようとしています。 /usr/share はアーキテクチャに依存しないファイルを保存するためのディレクトリであり、特定のアーキテクチャでのみ利用可能なバイナリ (C 言語でコンパイルされたコード) は、 %libexecdir/パッケージ名 などのディレクトリにインストールされるべきです。

特定のパッケージに対する例外として、このチェックはパスがアーキテクチャ固有のものである場合に警告を回避する仕組みがあります。たとえば /usr/share/tetex/bin/linux/x86/tetex などのディレクトリがそれに該当します。ただし、このような例外はお勧めしません。

wrong-script-interpreter

このスクリプトはシェバン (#!) で不正なインタプリタを使用しています。スクリプトのインタプリタはパッケージとして用意されたインタプリタのフルパスであるべきで、 /usr/local/bin などを参照すべきではありません。


arch-independent-package-contains-binary-or-object

ご利用のパッケージは noarch (アーキテクチャ非依存) としてマークされていますが、アーキテクチャ固有のバイナリが含まれてしまっています。

library-without-ldconfig-postin

このパッケージはライブラリをインストールしていますが、 %post セクション内で ldconfig を呼び出していません。 ldconfig でキャッシュを更新しないと、ライブラリは正しく使用されない場合があります。これは、続けてインストールされるパッケージがライブラリを必要としていることがあるので、インストール時によく発生する問題です。

file-contains-buildroot

ファイル内の文字列が buildroot 以下のパスを示しています。パッケージには、パッケージ作成時の情報を含むべきではありません。

files-duplicate

パッケージ内に重複するファイルが存在しています。そのため、インストールの領域とパッケージのサイズを無駄に使用してしまっています。 %fdupes マクロをお使いになることをお勧めします。

summary-not-capitalized

パッケージの概要 (summary) は大文字で始めるべきであるほか、ドット (.) で終わるべきではありません。

executable-docs

%docdir 内にあるドキュメンテーションに実行可能なファイルが含まれています。ドキュメンテーションは実行可能であるべきではありません。

spurious-executable-perm

通常は実行されるべきではないファイルが、実行可能であるとしてパーミッションが設定されています。この警告は誤って発せられているものであることもありますので、これらの警告が正しいかどうかをきちんとレビューしたのち、必要であれば省略してください。

devel-file-in-non-devel-package

-devel サブパッケージ内に存在すべきファイルが含まれています。パッケージの内容を確認し、 -devel パッケージに分割することには下記の 2 つの利点があります:

  1. 自分自身ではコンパイルを行なわない消費者／ユーザに対して、インストール後のサイズを小さくすることができる
  2. 必要に応じて -devel サブパッケージを必要とするように依存関係を構築することができるため、利用者に利便性を提供することができます。 -devel パッケージをインストールする際、依存関係の指定で必要なすべてのツールについてもインストールしなければならなくなるため、トラブルシューティングをより簡単にすることができます。

このチェックでは、下記の条件に該当するものがないかどうかについてもサブチェックで調査します。

  • /usr/include ヘッダファイルが存在していないかどうか。 .h で終わるファイルのほか、他のいくつかの拡張子もヘッダファイルとして認識します。
  • %libdir 内にバージョン番号付きの .so ファイルへのシンボリックリンクがあるかどうか。通常、これらのファイルは構築時にのみ必要ですが、何らかの理由で dlopen(3) を利用してライブラリを開くようなアプリケーションがあった場合、 .so ファイルを同梱させるのに十分な理由となります。しかしながら、これは稀なケースです。

また、このエラーは libtool のモジュールにバージョン番号が設定されている場合にも発生します。プラグインを構築する際には LDFLAGS に -avoid-version と -module を指定して、このチェックについても引っかからないようにしてください。

たとえば特定の共有ライブラリの目的が、他のアプリケーションで読み込まれるプラグインとなるためのものであった場合 (一般に %libdir ではなく %libdir のサブディレクトリにインストールされ、 /etc/ld.so.conf には書かれていないサブディレクトリであるもの) は、このモジュールを構築する際の LDFLAGS の指定を確認して、 -module と -avoid-version が指定されていることをご確認ください。この場合、ファイル名でバージョンを表すのではなく、プラグインをインストールするディレクトリそのものにバージョン番号を設定してください。

wrong-file-end-of-line-encoding

いくつかのファイルが DOS 形式 (CRLF) の改行を使用しています。環境によっては、閲覧アプリケーションで非互換性を生む原因ともなります。このチェックのスコアは非常に低い値に設定されているため、基本的には気にしなくても問題はありません。ただし、ファイルの保存にあたっては、できる限り Unix 形式 (LF のみ) を使用してください。

なお、 dos2unix を iso モードで 使用してはなりません 。なぜなら、これは CRLF を LF に変換するだけでなく、エンコーディングを CP437 から ISO-8859-1 に変換してしまうからです。そのため、 %prep セクション内で下記のいずれかの方法で改行のみを変換してください:

  • dos2unix -c ascii file
  • perl -i -pe 's/\r\n/\n/gs' file
  • sed -i 's/\r$//' file
  • sed -i 's/\r//' file (こちらについては '\n が続かない '\r' も削除してしまうため、不正確な変換結果になります)


wrong-script-end-of-line-encoding

E: foo-package wrong-script-end-of-line-encoding /var/www/foo-package/plugins/foo.php

このスクリプトには誤った行末のエンコーディングがなされています。一般的には、 Unix 以外のシステムで作成したり編集したりすることで発生します。これによってスクリプトが実行できなくなってしまいます。解決策は簡単で、 Linux のみでファイルを作成するものとし、 Unix 以外の環境でファイルを作成してパッケージに追加したりしなければよいのです。

hardlink-across-partition

構築したパッケージ内にハードリンクされた 2 つのファイルがありますが、これらのファイルは一般に、異なるパーティションに存在する可能性があります。このような RPM をそのような環境にインストールしようとすると、ハードリンクを展開することができずに失敗してしまいます。ポリシーでは、最初の 2 レベルのパスが異なる場合、ハードリンクを作成してはなりません。たとえば /srv/ftp と /srv/www や、 /etc と /usr などが該当します。

invalid-spec-name

spec ファイルは %name.spec の名前であるべきです。

no-packager-tag

spec ファイル内に "Packager" のタグが含まれていません。 (注意: 他の誰かが spec ファイルを利用してパッケージを再構築したような場合、 "Packager" タグを書き換えずに実施してしまうことがあり、それによってパッケージのバグを異なる人に報告してしまうことがあるため、 spec ファイルではこれを含むべきではありません。)

static-library-without-debuginfo

パッケージ内にある静的ライブラリに、デバッグ情報が含まれていません。一般的にこれらは必要性の低いファイルであるため、 --disable-static の configure オプションを指定するか、そのようなオプションがない場合、 %install セクションの最後で rm %buildroot/%_libdir/*.a を実行して削除してください。

shlib-legacy-policy-name-error

お使いのパッケージが SUSE 共有ライブラリパッケージングポリシー に従っていません。

shlib-policy-name-error

お使いのパッケージが SUSE 共有ライブラリパッケージングポリシー に従っていません。

ghost-files-without-postin

RPM ファイル内には含まれていないものの、パッケージによってインストール時、もしくはデーモンの起動時などに動的にファイルが作成されるものがあります (一般的には状態を表すファイルやログファイルなど) 。これらを spec ファイル内のファイル指定に記載してしまうと、 rpm -e を実行してパッケージを削除した場合に、これらも削除されてしまいます。

no-default-runlevel

init スクリプト内の INIT INFO セクションには、何らかの "Default-Start" タグが記載されているべきです。

init-script-runlevel-4

init スクリプトが、管理者側で自由に定義を決められるランレベル 4 を参照しています。ディストリビューションのスクリプトでは、このランレベルは使用してはなりません。 'Default-Start' から '4' を削除してください。

dbus-policy-missing-allow

dbus パッケージは以前、許可範囲の大きい設定を使用していたため、セキュリティ上の問題 (CVE-2008-4311) を発生させてしまいました。この問題の調査過程で、多くのパッケージの dbus 設定ファイルに不要な設定が含まれていて、これによって他のサービスに有害な影響を与えてしまっていたり、 dbus のセキュリティ更新後に設定を壊してしまったりするような問題が見つかりました。

この問題は各パッケージの dbus 設定ファイルを修正することで解決します。多くの場合、設定は数行程度にまで小さくなります。詳しくは https://bugs.launchpad.net/ubuntu/+source/avahi/+bug/318783 をお読みください。

この場合、 dbus の設定には下記のような形式の行が必要となります: <allow send_destination="org.foo.bar"/>

上記のような行が存在していないと、既定のポリシーは deny (拒否) であることから、サービスは dbus 上でうまく動作しません。

dbus-policy-deny-without-destination

'deny' ディレクティブを使用する際には、必ず 'send_destination' を指定しなければなりません。 指定しないと、他のサービスへのメッセージもブロックされてしまいます。

解決方法: ファイルに 'send_destination' タグを追加する

dbus-policy-allow-without-destination

'allow' ディレクティブを使用する際には、必ず 'send_destination' を指定しなければなりません。 指定しないと、他のサービスへのメッセージも無関係に許可されてしまいます。

解決方法: ファイルに 'send_destination' タグを追加する

dbus-policy-allow-receive

dbus ファイル内に不要な "allow receive_..." ディレクティブが含まれています。

解決方法: 削除する

executable-stack

rpmlint の出力: "The binary declares the stack as executable. Executable stack is usually an error as it is only needed if the code contains GCC trampolines or similar constructs which uses code on the stack. One common source for needlessly executable stack cases are object files built from assembler files which do not define a proper .note.GNU-stack section." (翻訳: "このバイナリでは、スタックを実行可能としてマークしています。スタックを実行可能にするという行為は、通常はエラーであり、 GCC トランポリンやスタック上でコードを使用するような類似のコンストラクトなど、限られた状況下でのみ必要なものです。不要な状況下であるにも関わらずスタックを実行可能にしてしまう例としては、適切な .note.GNU-stack セクションが定義されていないアセンブラファイルからオブジェクトを構築した場合などが考えられます。")

解決方法:

  • この問題に対して広い範囲を記述した文書が http://www.gentoo.org/proj/en/hardened/gnu-stack.xml にあります。
  • 最も簡単な解決方法は、おそらくリンカに対して -Wl,-z,noexecstack を指定することでしょう。
  • Build Service のプロジェクト、または `obs build --debug` などを利用して、 debuginfo サブパッケージを忘れずに生成してください。

generic-name-not-in-filelist

rpmlint の出力: "The generic name is not in a filelist of package, add it to list marked as %ghost. Note: this error will be raised, if you use a hash ($) in file name, use rpm macros in spec file instead." (翻訳: "汎用の名前がパッケージの filelist 内に存在していません。これを %ghost を指定して一覧に追加してください。注意: このエラーは、ファイル名にハッシュ ($) を使用している場合に発生します。 spec ファイル内ではハッシュの代わりに rpm マクロを使用してください。")

解決方法: 下記 をお読みください。

generic-name-not-marked-as-ghost

rpmlint の出力: "The generic name is not marked as a ghost, which may cause a problems during update. Mark it as a %ghost in %files section." (翻訳: "汎用の名前が ghost としてマークされていません。更新時に問題が発生する場合がありますので、 %files セクション内では %ghost を指定してください。")

解決方法: 汎用の名前 (たとえば Java 仮想マシンの場合は /usr/bin/java など) は %ghost としてマークしてファイルの一覧内に記載すべきです。これは更新や置き換えの処理が適切に行なわれるようにするためです。また、他の場合では、特定の状況下で rpm がファイルシステムからそれらを削除してしまい、リンクを壊してしまう場合があります。

警告: このポリシーは openSUSE 11.2 もしくはそれ以降のバージョンにのみ当てはまります。それ以前のバージョンでは、複数のパッケージで同じ ghost ファイルを所有している場合、インストールの際に競合が発生します。

たとえば zabbix パッケージ (プロジェクト: server:monitoring) では、下記のように指定しています: 

%install
...
# Ghost files must exists in a build root
touch %buildroot/%_sbindir/zabbix-server
touch %buildroot/%_sbindir/zabbix-proxy

%post server-mysql
%_sbindir/update-alternatives \
   --install %_sbindir/zabbix-server \
   zabbix-server \
   %_sbindir/zabbix-server-mysql 11

%files server-mysql
%defattr(-,root,root)
%if 0%{?suse_version} >= 1120
%ghost %_sbindir/zabbix-server
%endif
%_sbindir/zabbix-server-mysql

なお、 ghost ファイルは buildroot 内に存在していなければならないことに注意してください。

no-binary

E: foo-package no-binary

このパッケージにはバイナリが含まれていないため、 noarch のアーキテクチャを使用すべきです。解決策としては、 spec ファイル内に "BuildArchitectures: noarch" を指定してください。ただし、 Python パッケージの際は意味のない警告なので、この警告は無視してかまいません。

standard-dir-owned-by-package

E: foo-package standard-dir-owned-by-package /usr/share

このパッケージには、標準の階層構造に含まれるディレクトリが含まれています。これにより、既定のディレクトリパーミッションや所有権が非標準のものに書き換えられてしまいます。 %files 内にはシステム標準のディレクトリは含めないでください。

non-conffile-in-etc

W: foo-package non-conffile-in-etc /etc/xdg/menus/applications-merged/foo-package.menu

お使いのパッケージから /etc に対して、実行ファイルではなく設定ファイルでもないファイルをインストールしようとしています。 /etc 内では、実行ファイル以外には設定ファイルのみがインストールされるべきです。 spec ファイル内では、支持されたファイルに %config または %config(noreplace) のディレクティブを指定してください。

summary-ended-with-dot

W: foo-package summary-ended-with-dot A content management system for foo package.

概要の文章がドット (.) で終わってしまっています。ドットを削除してください。

script-without-shebang

E: foo-package script-without-shebang /var/www/foo-package/plugins/foo.php

この実行可能なテキストファイルにはシェバン (#!) が含まれていないため、適切に実行することができません。スクリプトではないファイルに対して、実行可能なビットが設定されている場合に表示されるほか、シェバンが書かれていない場合にも表示されます。このエラーを修正するには、まずどちらのケースに該当するのかを判断し、実行可能ビットを削除するかシェバンを追加してください。

version-control-internal-file

E: foo-package version-control-internal-file /var/www/foo-package/CVS/Entries

パッケージ内に、バージョン制御システム (CVS) が内部的に使用するファイルが含まれています。これらのファイルはパッケージ内に含めないでください。

解決方法: CVS のディレクトリとその中にあるファイルは、単純に削除しておくべきです。

zero-length

E: foo-package zero-length /var/www/foo-package/foo.js

長さ 0 のファイルが存在しています。

解決方法: あえてインストールしているようなことはほとんどなく、通常は削除すべきです。下記のコマンドを実行することで、インストール後のディレクトリ内にある長さ 0 のファイルを検出することができます: 

find %{buildroot} -size 0 -delete

non-standard-group

W: foo-package non-standard-group Networking/Other

spec ファイル内で指定しているグループが正しくありません。 既知のもの からいずれかを選択してください。

strange-permission

W: foo-package strange-permission foo-package.spec 0744

パッケージ内に存在するファイルに、奇妙なパーミッション設定のものがあります。通常のファイルであれば 0644 (rw-r--r--) のパーミッションであるべきであるし、ディレクトリであれば 0755 (rwxr-xr-x) であるべきです。

hardcoded-library-path

E: foo-package hardcoded-library-path in %{buildroot}/usr/lib/menu/

下記のパスに対するライブラリがハードコードされています: /lib, /usr/lib 。これらはいずれも /%_lib や %_libdir に置き換えられるべきです。

suse-filelist-forbidden-noarch

E: suse-filelist-forbidden-noarch /usr/lib64/aspell-0.60/english-huge.multi is not allowed in a noarch package

パッケージ側ではアーキテクチャに依存していないものであるとしているにも関わらず、アーキテクチャに固有のパスが含まれてしまっています。アーキテクチャに中立な場所に移動するか、パッケージ側の noarch タグを削除してください。

incoherent-init-script-name

W: incoherent-init-script-name haldaemon ('hal', 'hald')

init スクリプトの名前はパッケージ名を小文字にしたものと同じか、もしくは末尾に 'd' を追加したものであるべきです。

解決方法: チェックで提案されたとおりに init スクリプトの名前を変更してください。

unstripped-binary-or-object

このエラーは、 Build Service 内では決して表示されることはありません。構築用のスクリプトがグローバルのプロジェクト設定に従い、自動的にバイナリを strip するためです。そのため、このようなエラーが発生した場合は自動化された strip 処理に何らかの問題が発生していることになりますので、バグとして報告してください。 なお、手作業でバイナリを strip したりはしないでください。手作業で行なってしまうと、 debuginfo の作成が失敗してしまうためです。

binary-or-shlib-calls-gethostbyname

gethostbyname*() と gethostbyaddr*() の各関数は IPv6 環境で利用できないため、廃止対象となっています。これらの関数の代わりに、アプリケーションは getaddrinfo(3) と getnameinfo(3) を使用すべきです。アップストリーム (提供元) のプロジェクトと連携して、アプリケーションを新しいインターフェイスに対応させてください。

なお、 Ulrich Drepper 氏がこの問題についてさらに詳しく説明しています。

file-not-in-%lang

W: file-not-in-%lang /usr/share/sarg/sarg-php/locale/en_EN/LC_MESSAGES/messages.mo

gettext の翻訳ファイル (.mo で終わるファイル) が言語ファイルとしてタグ付けされていません。この情報は、将来的にインストール時に特定の言語を除外したりする際に便利な仕組みです。 %find_lang マクロを利用することで、自動的にファイルにタグを設定することができます。

untranslated-desktop-file

テンプレート:Section cleanup

.desktop ファイルが SUSE 用に翻訳タグが設定されていないことにより、翻訳上の問題がよく発生します。この翻訳を動作させるには、これらのファイルのそれぞれに対して %suse_update_desktop_file を実行しなければなりません。これにより、 openSUSE の翻訳担当者と SUSE の翻訳チームが作業を行ない、パッケージの構築時に .desktop ファイルに対して翻訳データを設定することができるようになります。

なお、 KDE3 や KDE4 のパッケージの場合、このエラーは %install セクションの終わりで %kde_post_install を実行していない場合にも発生します。

init-script-without-%stop_on_removal-preun

このパッケージには /etc/init.d のスクリプトが含まれていますが、 %preun スクリプト内で %stop_on_removal を呼び出していません。詳しくは パッケージ規約 をお読みください。

init-script-without-%insserv_cleanup-postun

このパッケージには /etc/init.d のスクリプトが含まれていますが、 %postun スクリプト内で %insserv_cleanup を呼び出していません。詳しくは パッケージ規約 をお読みください。

no-prereq-on

このパッケージの %pre, %post, %preun, %postun のいずれかのスクリプトで外部バイナリを参照していますが、適切な Requires タグ (Requires(pre):, Requires(post):, Requires:, Requires: のいずれか) が指定されていません。この問題は、パッケージのインストールまたは削除の際、それを正しい順序で実施するために解決する必要があります (たとえば %post スクリプトを実行するには、その時点までにパッケージがインストールされていなければならないなど) 。

non-ghost-in-var-run

新しいディストリビューションでは /var/run が tmpfs でマウントされるため、その中身は揮発的な存在になります (つまり、システムを再起動するとファイルが失われます) 。そのため、パッケージがこのディレクトリにファイルをインストールしても、意味がないことになります。

解決方法: spec ファイル内では対象のファイルを %ghost としてマークし、実行時に init スクリプトなどからファイルを作成 (touch) するようにしてください。パッケージに init スクリプトがない場合は、 /usr/lib/tmpfiles.d で指定してください。

non-ghost-in-var-lock

新しいディストリビューションでは /var/lock が tmpfs でマウントされるため、その中身は揮発的な存在になります (つまり、システムを再起動するとファイルが失われます) 。そのため、パッケージがこのディレクトリにファイルをインストールしても、意味がないことになります。また、このディレクトリは lockdev で管理される古いデバイスのロックファイル (例: LCK..ttyS0) を作成するためのディレクトリです。他の用途で使用してはなりません。

subsys-unsupported

/var/lock/subsys は使用されておらず、 openSUSE ではサポートもされていません。他のディストリビューションでは実行中のinit スクリプトをマークするのに使用しています。 openSUSE ではこの用途に使用するディレクトリはありません。そのため、多くの場合において /var/lock/subsys への参照は、置き換え無しに削除すべきです。どうしても init スクリプト側で状態の保存用に左記のディレクトリが必要となる場合は、代わりに /var/run/rc(名前) などのファイルを使用してください。 /var/lock を使用してはならない理由については、上の章をお読みください。

non-position-independent-executable

ディストリビューションごとのポリシーにより、重要なネットワーク通信プログラムや setuid のバイナリなど、いくつかのバイナリについては、 position independent executable (PIE) としてコンパイルする必要があります。 PIE はプログラムに対して、開始アドレスをランダムに決めて実行するようにするため、悪意のある攻撃者から弱点を突きにくくすることができます。このようなバイナリを作成するには、 CFLAGS に -fPIE を、 LDFLAGS に -pie を指定します。

たとえば util-linux では、下記の行を Makefile.am に追加することで解決しています: 

 write_CFLAGS = $(SUID_CFLAGS) $(AM_CFLAGS)
 write_LDFLAGS = $(SUID_LDFLAGS) $(AM_LDFLAGS)

spec ファイルでは下記のように指定しています: 

 export SUID_CFLAGS=-fPIE
 export SUID_LDFLAGS=-pie
 %configure ...

polkit-unauthorized-privilege

このパッケージは、特権の必要な操作を認証なしで非特権ユーザに実行できるようにしてしまっています。この問題は注意して対応しないと、セキュリティ上の問題を引き起こします。パッケージを SUSE 製品に取り込もうとしている場合にこの問題に直面した場合は、バグ報告を行なって、セキュリティチームに対してパッケージのレビューを依頼してください。

suse-dbus-unauthorized-service

このパッケージは DBUS システムのサービスファイルをインストールしています。 DBUS サービスは通常、非特権ユーザの代理として root ユーザで実行されるもので、セキュリティ問題の原因ともなります。そのため、パッケージを SUSE 製品に取り込もうとしている場合にこの問題に直面した場合は、バグ報告を行なって、セキュリティチームに対してパッケージのレビューを依頼してください。

no-changelogname-tag

パッケージ内に changelog が含まれていません。 spec ファイルの最終行に %changelog タグを追加したあと、 'osc vc' コマンドで .changes ファイルを作成してください。

suse-logrotate-user-writable-log-dir

/etc/logrotate.d/* ファイル内で指定しているディレクトリが、 root 以外のユーザもしくはグループから書き込めるようになってしまっています。 logrotate は root で動作する仕組みであるため、 logrotate を騙して実行させることもできてしまうことになります (たとえばシンボリックリンク攻撃 CVE-2011-1155 など) 。正しく修正するには、ログファイルのディレクトリを root のみが書き込めるようにします。ログファイルそのものに対しては、他のユーザが所有していてもかまいません。また、 logrotate の 'create' オプションでは、切り替えたログファイルに対して正しいパーミッションを設定するようにすることができます。なお、サービス側の都合で、ディレクトリに対して異なる所有権を設定する必要がある場合は、 logrotate の設定で "su" オプションを指定してください (詳しくはマニュアルページをお読みください) 。これは、どうしても適切なディレクトリパーミッションが設定できない場合にのみ使用すべき、最終手段です。

suse-logrotate-log-dir-not-packaged

/etc/logrotate.d/* ファイル内で指定しているディレクトリが、パッケージの %files セクション内に含まれていません。そのため、 rpmlint はディレクトリのパーミッションが適切かどうかを確認することができません。 %files 内でそれらのディレクトリを指定してください。

permissions-suseconfig-obsolete

%run_permissions は、 SuSEconfig を呼び出してシステム内にあるすべてのファイルのパーミッションを設定します。パッケージに含まれるファイルに対してのみパーミッションを設定するため、 %set_permissions を利用するように修正してください。 

 %if 0%{?suse_version} <= 1130
 %run_permissions
 %else
 %set_permissions /usr/bin/foo /usr/bin/bar
 %endif

permissions-missing-verifyscript

パッケージには、対象のバイナリをチェックする仕組みである verifyscript が含まれていません。適切な %verifyscript セクションを追加してください。 

 %verifyscript
 %verify_permissions -e /usr/bin/foo -e /usr/bin/bar

suse-missing-rclink

init スクリプトや systemd のユニットファイルが含まれるパッケージの場合、サービスの再起動を簡単に行なえるようにするため、 'rc' に続いてサービス名の続くシンボリックリンクを含めるべきです。

たとえば /etc/init.d/foo という init スクリプトがあるパッケージの場合、シンボリックリンクは /etc/init.d/foo を指し示す /usr/sbin/rcfoo であるべきです。

また、たとえば /usr/lib/systemd/system/foo.service という systemd ユニットファイルがあるパッケージの場合は、シンボリックリンクは /usr/sbin/service (systemctl のラッパー) を指し示す /usr/sbin/rcfoo であるべきです。

suse-systemd-shadowed-initscript

このパッケージには init スクリプトと systemd のサービスファイルの両方が含まれています。 init スクリプトと systemd のサービスファイルが同じ名前の場合、 init スクリプト側は systemd 側で無視されますが、混乱を防ぐために init スクリプト側を削除すべきです。

なお、 init スクリプトは通常の start/stop/status など以外の機能を実装している場合があります。 systemd のサービスファイルでは、このような機能はありませんので、 /usr/sbin/service で "レガシーアクション" に対応しています。詳しくは openSUSE:Systemd パッケージングガイドライン#追加のアクション をお読みください。

suse-branding-specific-branding-req

パッケージ側では、異なるテーマの利用を許す目的で、特定のブランディングやテーマパッケージを必要としてはなりません。

たとえば下記のようにします: 

 Name: foo
 Requires: foo-branding

 Name: foo-branding-upstream
 Provides: foo-branding

 Name: foo-branding-openSUSE
 Provides: foo-branding

dir-or-file-in-var-run

/var/run は現在はシンボリックリンクであるため、このディレクトリ内のファイルをパッケージに入れてはなりません。代わりに /run を使用してください。

dir-or-file-in-var-lock

/var/lock は現在はシンボリックリンクであるため、このディレクトリ内のファイルをパッケージに入れてはなりません。このような仕組みは取り除いてください。 lockdev パッケージが独占的に使用すべきものです。

rpmbuild

"Files not owned by a package" メッセージ

rpmbuild から下記のようなメッセージが表示された場合は、 必ず %files セクション内にこれらを追加してください: 

foobar-0-0.noarch.rpm: directories not owned by a package:
 - /etc/php5
 - /etc/php5/conf.d

ただし、 standard-dir-owned-by-package という rpmlint 警告が表示された場合を除きます。これは、 foobar と php5 の両方をシステムから削除するような場合、 php5 が foobar よりも前に削除されることがあるため、 php5 の削除の時点で (例えば) /etc/php5/conf.d/foobar.ini ファイルが残るため、 /etc/php5 が削除されなくなってしまうためです。ただし、唯一の所有者であった php5 は削除されてしまっているため、 /etc/php5 はどのパッケージにも所有されていない状態になります。

「https://ja.opensuse.org/index.php?title=openSUSE:パッケージングチェック&oldid=6313」から取得