From Fedora Project Wiki
m (Remove Packaging guidelines category)
 
(46 intermediate revisions by one other user not shown)
Line 88: Line 88:
== 既存のパッケージからの修正 ==
== 既存のパッケージからの修正 ==


既存の Fedora 以外のパッケージをベースにする場合、その正当性の検証と厳密に何が発生するかを理解することに注意してください。何か変なことが起こらないかを調べずにパッケージを追加するように提案しないでください。一見、害が無さそうに見えるコマンドも調査対象になります。
既存の Fedora パッケージ以外のパッケージをベースにする場合、その正当性の検証とそのパッケージをインストールして使用することで何か問題が発生しないかを厳密に調査するようにしてください。何か変なことが起こらないかを調査していない状態でパッケージを追加するように提案しないでください。一見、害が無さそうに見えるコマンドも調査対象になります。


特に次のことをすべきです。
特に次のことをすべきです。
Line 180: Line 180:
</pre>
</pre>


changelog のエントリは、新たなバージョン番号、追加されたパッチ、その他の spec ファイルの修正、バグや、もしあれば CVE のエントリを含めたリリース間でそのパッケージに対して行われた変更内容の簡潔な要約を記載すべきです。絶対に変更された全ソースのコピーを CHANGELOG エントリに含めてはいけません。その目的は、多くの技術的な詳細とその変更内容でうんざりさせることなくアップデートされたパッケージで何が変更されたかについて、ユーザへヒントを与えることです。アップストリームの changelog へのリンクは追加情報を望むユーザのために含めることができます。


{{Anchor|tags}}
{{Anchor|tags}}
Line 244: Line 245:
=== ファイルの依存関係 ===
=== ファイルの依存関係 ===


Rpm gives you the ability to depend on files instead of packages.  Whenever possible you should avoid file dependencies outside of /etc, /bin, /sbin, /usr/bin, or /usr/sbin.  Using file dependencies outside of those directories requires yum (and other depsolvers using the repomd format) to download and parse a large xml file looking for the dependency. Helping the depsolvers avoid this processing by depending on the package instead of the file saves our end users a lot of time. There are times when other technical considerations outweigh these considerations. One specific example is packages installing into %{_libdir}/mozilla/plugins. In this case, mandating a specific browser in your package just to own this directory could drag in a large amount of needless packages. Requiring the directory to resolve the dependency is the better choice.
rpm にはパッケージの代わりにファイルの依存関係を持つ機能もあります。できるだけ /etc, /bin, /sbin, /usr/bin 又は /usr/sbin 以外でファイルの依存関係を使用しないようにしてください。そのようなディレクトリ以外のファイルの依存関係を使用することは依存関係を探す巨大な xml ファイルをダウンロードして解析するために yum (や repmod 形式を使用するその他の依存関係解決ツール)を必要とします。エンドユーザに待ち時間を取らせないために、ファイルではなくパッケージの依存関係を持たせることで依存関係解決ツールはこの処理を行いません。ファイルの依存関係は、こういった懸念事項よりも優先する他の技術的な検討事項があるときもあります。特別な例の1つとして %{_libdir}/mozilla/plugins にインストールされるパッケージです。この場合、ただこのディレクトリを所有するために特定ブラウザをパッケージの依存関係に持つと、多くの不要なパッケージを一緒にインストールされてしまいます。そういった依存関係を解決するためにディレクトリを要求する方が良い選択でしょう。


{{Anchor|ExplicitRequires}}
{{Anchor|ExplicitRequires}}
=== 明示的な Requires ===
=== 明示的な Requires ===
Packages must not contain explicit ''Requires'' on libraries except when absolutely
necessary. When explicit library ''Requires'' are necessary, there should be a spec file comment justifying it.


We generally rely on rpmbuild to automatically add dependencies on library SONAMEs.
明示的な Requires とは spec ファイルでパッケージャが手動で追加した Requires です。パッケージには絶対的に必要な場合を除いてライブラリの明示的な ''Requires'' を定義してはいけません。明示的なライブラリの ''Requires'' が必要なときは、そのことを説明するコメントを spec ファイルに残すべきです。
Modern package management tools are capable of resolving such dependencies to determine
 
the required packages. Explicit dependencies on specific package names may aid the
一般的にはライブラリの SONAME の依存関係を自動的に追加する rpmbuild を信頼します。最近のパッケージ管理ツールは必要なパッケージを探してきて依存関係を解決する機能があります。特定のパッケージの明示的な依存関係は手動で RPM パッケージをインストールしようとしている経験の浅いユーザにとっては助けになるかもしれません。しかし、ライブラリ/ファイルをあるパッケージから別のものに移行した場合、パッケージ名が変更された場合、複数の代替パッケージのうち1つだけあれば十分な場合、バージョン指定された明示的な依存関係が古くなってしまった場合など、このような依存関係は混乱を招くことがこれまでの歴史から分かっています。さらに、あるケースでは、古い明示的な依存関係が不要なアップデート/リビルドを要求します。例えば、Fedora パッケージは2回のフルリリースサイクル向けに、過去の Provides を維持するためにのみ Requires します。
inexperienced user, who attempts at installing RPM packages manually, however, history
 
has shown that such dependencies add confusion when library/files are moved from one
バージョン指定された明示的な依存関係のための模範的な定義は次の通りです。
package to another, when packages get renamed, when one out of multiple alternative
packages would suffice, and when versioned explicit dependencies become out-of-date and
inaccurate. Additionally, in some cases, old explicit dependencies on package names
require unnecessary updates/rebuilds. For example, Fedora packages are only required
to retain historical provides for two full release cycles.


Exemplary rationale for a versioned explicit dependency:
<pre>
<pre>
   # The automatic dependency on libfubar.so.1 is insufficient,
   # libfubar.so.1 の自動検出される依存関係は十分ではありません
   # as we strictly need at least the release that fixes two segfaults.
   # 最低でも2つのセグメンテーションフォールトを修正したリリースを厳密に必要とします
   Requires: libfubar >= 0:1.2.3-7
   Requires: libfubar >= 0:1.2.3-7
</pre>
</pre>


Packagers should revisit an explicit dependency as appropriate to avoid
パッケージャは明示的な依存関係が不正確で余分なものにならないように、必要に応じて見直すべきです。上述した例において、現時点の Fedora リリースが libfubar < 1.2.3-7 を提供していないなら、この明示的なバージョン指定された依存関係を今後も残しておく必要はありません。
it becoming inaccurate and superfluous.  For instance in the example above, when no current Fedora release shipped with libfubar < 1.2.3-7, it is no longer necessary to list the explicit, versioned requirement.


=== 自動生成された Requires をフィルタリングすること ===
=== 自動生成された Requires/Provides を取り除く ===
RPM attempts to auto-generate Requires (and Provides) at build time, but in some situations, the auto-generated Requires/Provides are not correct or not wanted. For more details on how to filter out auto-generated Requires or Provides, please see: [[Packaging:AutoProvidesAndRequiresFiltering]]
 
RPM は Requires/Provides をビルド時に自動生成しようとしますが、状況によっては、自動生成された Requires/Provides は正しくないものか、望まないものです。自動生成された Requires/Provides を取り除く方法の詳細については [[Packaging:AutoProvidesAndRequiresFiltering]] を参照してください。


{{Anchor|BuildRequires}}
{{Anchor|BuildRequires}}
Line 279: Line 273:
== BuildRequires ==
== BuildRequires ==


In package development and testing, please verify that your package is not missing any necessary build dependencies. Having proper build requirements saves the time of all developers and testers as well as autobuild systems because they will not need to search for missing build requirements manually. It is also a safety feature that prevents builds with that would not otherwise fail, but would be missing crucial features. For example, a graphical application may exclude PNG support after its '''configure''' script detects that libpng is not installed.
パッケージ開発やテストの中で、ビルドに必要な依存関係が欠落していないかを検証してください。適切なビルドのための依存関係を定義することは自動ビルドシステムと同様に、全ての開発者とテスターの作業を効率化します。というのは、手動で欠落したビルドの依存関係を探す必要がないからです。また、それは何らかの要因によるビルドエラーではなく、極めて重要な機能を欠落させた状態でビルドしないようにするための安全な機能です。例えば、グラフのアプリケーションは、そのパッケージの '''configure''' スクリプトによって libpng がインストールされていないことを検出すると PNG サポートを排除するかもしれません。


Before adding Build<code></code>Requires to any package, please be comfortable with [[#Requires| Requires]] .
Build<code></code>Requires をパッケージへ追加する前に、[[#Requires| Requires]] を適切に定義してください。


There are two suggested ways of detecting missing Build<code></code>Requires. '''rpmdev-rmdevelrpms''' and '''mock'''. The first one is designed to remove all developer-related packages from your system. If the build fails or is missing certain features due to missing build dependencies, then the missing dependency needs to be found and added. Check the [[#rmdevelrpms| rpmdev-rmdevelrpms]] section to find out more. <BR>
欠落した Build<code></code>Requires を検出する方法として2つの方法が提案されています。'''rpmdev-rmdevelrpms''' と '''mock''' です。'''rpmdev-rmdevelrpms''' はシステムから全ての開発関連パッケージを削除するように設計されています。もしビルドに失敗するか、ビルドのための依存関係が欠落して特定の機能がなくなってしまったら、欠落した依存関係を探して追加されます。詳細は[[#rmdevelrpms| rpmdev-rmdevelrpms]] セクションを参照してください。<BR>
'''mock''' is another good way to check build dependencies. Rather than remove all developer packages, it tries to build your package in a chroot. It makes no changes to your normal, daily environment and ensures that your package will build fine. However, '''mock''' may need a good internet connection to download all required packages. [[Extras/MockTricks| MockTricks]] page contains more information. Another mock-like tool, '''mach''' is also available in the Fedora repository.
'''mock''' はビルドの依存関係を確認する優れたもう1つの方法です。全ての開発関連パッケージ削除するよりも、chroot を行ってパッケージをビルドしようとします。その方法だと、通常の、毎日使用する環境を変更する必要はありません。そして、パッケージが正常にビルドされることを確認します。しかし、'''mock''' は要求された全てのパッケージをダウンロードするためにインターネットとの接続が必要です。[[Extras/MockTricks| MockTricks]] に詳細があります。他に mock に似たツールで、 '''mach''' も Fedora のリポジトリで利用することができます。


{{Anchor|rmdevelrpms}}
{{Anchor|rmdevelrpms}}
=== rpmdev-rmdevelrpms ===
=== rpmdev-rmdevelrpms ===


'''rpmdev-rmdevelrpms''' script within the [[rpmdevtools]]  toolkit is a script written by Ville Skyttä that helps RPM packagers in finding missing Build<code></code>Requires. Simply run it and allow it to remove all *-devel packages and build tools like this example.
[[rpmdevtools]] ツールキットに含まれている '''rpmdev-rmdevelrpms''' スクリプトは、欠落した Build<code></code>Requires を探すために Ville Skyttä によって開発されました。シンプルにそのスクリプトを実行して、この例のような全ての *-devel パッケージとビルドツールを削除してください。


<pre>
<pre>
Line 350: Line 344:
................................................................Done.
................................................................Done.
</pre>
</pre>
Then attempt to build your RPM package. Use yum to reinstall any packages that are already in Build<code></code>Requires. If your build fails after this point, then you need to read through the build process and ascertain the missing Build<code></code>Requires from the error messages within.
その後、あなたの RPM パッケージをビルドしようとしてください。既に Build<code></code>Requires に定義しているパッケージは yum で再インストールしてください。もしこの時点でビルドに失敗したら、ビルド処理を調査する必要があります。そして、エラーログから欠落した Build<code></code>Requires を究明します。


Be very careful to watch especially the '''configure''' part of the build process for missing optional libraries or tools that are desirable for the package.
パッケージに望まれるツールか、オプションのライブラリが欠落していないか、ビルド処理の '''configure''' の部分を特に注意深く確認してください。


By default, the script may attempt to remove some packages that your system needs to operate correctly. Usually, this will fail due to an unsatisfied dependency (and this, BTW is why the script is using rpm -e instead of yum remove...)
デフォルトでは、'''rpmdev-rmdevelrpms''' スクリプトは、システムが正常に動作するために必要なパッケージを削除しようとするかもしれません。通常は、不十分な依存関係のために失敗するでしょう(これが、つまり yum remove の代わりに rpm -e を使用している理由です)。


An example of this are the gettext and libgcj packages. gettext is usually a development-only package, but for example redhat-lsb depends on it. Also, it seems that RH9 Konqueror needs openssl-devel for SSL. If you wish to mark some packages so that they will be ignored by rpmdev-rmdevelrpms, do it in /etc/rpmdevtools/rmdevelrpms.conf or your personal /.rmdevelrpmsrc and pay special attention to the packages you treated this way when building.
この例としては gettext や libgcj パッケージがあります。gettext は通常は開発のみに使用されるパッケージですが、例えば redhat-lsb は gettext に依存します。また、RH9 の Konqueror は SSL のために openssl-devel を必要とします。rpmdev-rmdevelrpms が無視するパッケージを幾つかマークしたいなら、/etc/rpmdevtools/rmdevelrpms.conf か、ホームディレクトリの .rmdevelrpmsrc にその内容を設定してください。そして、ビルド時はこの方法で設定した対象パッケージに対して十分に注意するようにしてください。


{{Anchor|Exceptions}}
{{Anchor|Exceptions}}
=== 例外事項 ===
=== 例外事項 ===


There is no need to include the following packages or their dependencies as Build<code></code>Requires because they would occur too often. These packages are considered the minimum build environment.
次のパッケージやその <code>BuildRequires</code> としての依存関係は、一般的によく使用されるので spec ファイルに定義する必要はありません。これらのパッケージは最小ビルド環境として認識されています。


<pre>
<pre>
Line 391: Line 386:
{{Anchor|summary}}
{{Anchor|summary}}


== 要約とパッケージ説明内容 ==
== 要約とパッケージ説明 ==
The summary should be a short and concise description of the package. The description expands upon this. Do not include installation instructions in the description; it is not a manual. If the package requires some manual configuration or there are other important instructions to the user, refer the user to the documentation in the package. Add a ''README.Fedora'', or similar, if you feel this is necessary. Also, please make sure that there are no lines in the description longer than 80 characters.


Please put personal preferences aside and use American English spelling in the summary and description. Packages can contain additional translated summary/description for supported Non-English languages, if available.
要約は短くパッケージの説明内容を簡潔にしたものにすべきです。パッケージ説明は要約から発展させます。パッケージ説明にインストールガイドを含めないでください。それはマニュアルではありません。パッケージが手動設定か、ユーザに対する重要なインストールガイドを必要とするなら、パッケージのドキュメントを参照させるようにしてください。必要だと思ったら ''README.Fedora'' か、似たようなものを追加してください。また、パッケージ説明の1行は80文字以上にならないように注意してください。
 
個人的な優先度は置いておいて、要約やパッケージ説明にはアメリカ英語のつづりを使用してください。パッケージには、可能なら非英語圏のために翻訳された要約やパッケージ説明を追加で含めることもできます。


=== 要約やパッケージ説明内容の商標 ===
=== 要約やパッケージ説明内容の商標 ===
Packagers should be careful how they use trademarks in Summary or Description. There are a few rules to follow:
* Never use "(TM)" or "(R)" (or the unicode equivalents, ™/®). It is incredibly complicated to use these properly, so it is actually safer for us to not use them at all.
* Use trademarks in a way that is not ambiguous. Avoid phrasing like "similar to" or "like". Some examples:


* '''BAD:''' It is similar to Adobe Photoshop.
パッケージャは要約やパッケージ説明に商標を使用する方法に注意すべきです。次にルールがあります。
* '''GOOD:''' It supports Adobe Photoshop PSD files, ...


* '''BAD:''' A Linux version of Microsoft Office
* 決して "(TM)"、"(R)" (又はユニコードの ™/®) を使用しないでください。これらのマークを適切に使用するには信じられないぐらい複雑です。そのため、これらのマークを全く使用しないのが我々にとっては安全です。
* '''GOOD:''' A word-processor with support for Microsoft Office DOC files
* 曖昧ではない方法で商標を使用してください。"似ている" とか "ような" というフレーズは避けてください。例があります。
* '''悪い例:''' Adobe Photoshop に似たものです
* '''良い例:''' Adobe Photoshop の PSD ファイルをサポートします ...
* '''悪い例:''' Microsoft Office の Linux バージョンです
* '''良い例:''' Microsoft Office の DOC ファイルをサポートするワードプロセッサです


If you're not sure, ask yourself, is there any chance someone may get confused and think that this package is the trademarked item? When in doubt, try to leave the trademark out.
あなたがよく分からないなら、誰かが混乱する可能性はないかと自問してください。そして、このパッケージは商標が必要かを考えてください。疑問に思ったら、商標を外すようにしてください。


{{Anchor|PackageEncoding}}
{{Anchor|PackageEncoding}}


== 文字エンコーディング ==
== 文字エンコーディング ==
Unless you need to use characters outside the [http://commons.wikimedia.org/wiki/Image:Ascii_full.png ASCII repertoire] , you will not need to be concerned about the encoding of the spec file. If you do need non-ASCII characters, save your spec files as UTF-8.  If you're in doubt as to what characters are ASCII, please refer to [http://commons.wikimedia.org/wiki/Image:Ascii_full.png this chart] .
 
[http://commons.wikimedia.org/wiki/Image:Ascii_full.png ASCII 文字の範囲]外で文字を使用する必要がない限り、spec ファイルのエンコーディングについて考慮する必要はないでしょう。ASCII 文字以外を使用する必要があるなら、UTF-8 で spec ファイルを記述するようにしてください。ASCII 文字が何なのか分からないなら、[http://commons.wikimedia.org/wiki/Image:Ascii_full.png このグラフ]を参照してください。


{{Anchor|FilenameEncoding}}
{{Anchor|FilenameEncoding}}
=== ASCII 文字ではないファイル名 ===
=== ASCII 文字ではないファイル名 ===
Similarly, filenames that contain non-ASCII characters must be encoded as UTF-8. Since there's no way to note which encoding the filename is in, using the same encoding for all filenames is the best way to ensure users can read the filenames properly. If upstream ships filenames that are not encoded in UTF-8 you can use a utility like convmv (from the convmv package) to convert the filename in your %install section.
 
同様に、ASCII 文字以外の文字を含むファイル名は UTF-8 でエンコードされなければなりません。ファイル名が何のエンコーディングかを設定する方法がないので、全てのファイル名に同じエンコーディングを使用することがユーザがファイル名を読めることを保証するために最も良い方法です。もしアップストリームが UTF-8 でエンコードされていないファイル名でリリースしていたら、%install セクションで(convmv パッケージにある)convmv のようなユーティリティを使用してファイル名を変換することができます。


{{Anchor|PackageDocumentation}}
{{Anchor|PackageDocumentation}}
== ドキュメント ==
== ドキュメント ==
Any relevant documentation included in the source distribution should be included in the package. Irrelevant documentation include build instructions, the omnipresent ''INSTALL'' file containing generic build instructions, for example, and documentation for non-Linux systems, e.g. ''README.MSDOS''.  Pay also attention about which subpackage you include documentation in, for example API documentation belongs in the -devel subpackage, not the main one.  Or if there's a lot of documentation, consider putting it into a subpackage.  In this case, it is recommended to use <code>*-doc</code> as the subpackage name, and <code>Documentation</code> as the value of the <code>Group</code> tag.


Also, if a package includes something as <code>%doc</code>, it must not affect the runtime of the application. To summarize: If it is in <code>%doc</code>, the program must run properly if it is not present.
配布されているソースに含まれる、いかなる関連ドキュメントもパッケージ内に含まれるべきです。ビルド方法については無関係なドキュメントもあります。よくある ''INSTALL'' ファイルは一般的なビルド方法について記載していたり、例えば、''README.MSDOS'' のように Linux 以外のシステムのドキュメントがあったりします。どのサブパッケージにドキュメントを含めるかにも注意を払ってください。例えば、API の例に関するドキュメントは -devel パッケージに含めて、メインパッケージには含めません。さらに大量にドキュメントがあるなら、サブパッケージに分割することを検討してください。この例では、サブパッケージの名前として <code>*-doc</code> が推奨されます。そして <code>Group</code> タグの設定は <code>Documentation</code> になります。
 
また、あるパッケージが <code>%doc</code> にドキュメントを含んでいるなら、アプリケーションの実行に影響を与えてはいけません。要約すると、ドキュメントが <code>%doc</code> にあるなら、そのプログラムはそこにドキュメントがなかったとしても正常に実行されなければなりません。


{{Anchor|CompilerFlags}}
{{Anchor|CompilerFlags}}
== コンパイラフラッグ ==
 
Compilers used to build packages should honor the applicable compiler flags set in the system rpm configuration.  As of Aug 2006, this means in practice $RPM_OPT_FLAGS/%{optflags} for C, C++, and Fortran compilers.  Honoring means that the contents of that variable is used as the basis of the flags actually used by the compiler during the package build.  Adding to and overriding or filtering parts of these flags is permitted if there's a good reason to do so; the rationale for doing so should be reviewed and documented in the specfile especially in the override and filter cases.
== コンパイラフラグ ==
 
パッケージをビルドするために使用するコンパイラはシステム内で rpm 設定としてセットされた適切なコンパイラフラグを受け取るべきです。2006年8月以降は、C/C++ や Fortran コンパイラのために $RPM_OPT_FLAGS/%{optflags} が実際に使用されます。その変数の中身がパッケージのビルドにおいてコンパイラによって実際に使用される基本フラグになります。このフラグをフィルタリングしたり、追加や上書きしたりすることは、理由があるときには許可されています。そのように変更する論理的根拠は、特に上書きやフィルターするときに spec ファイル内に記載してレビューされるべきです。


{{Anchor|Debuginfo}}
{{Anchor|Debuginfo}}
== Debuginfo パッケージ ==
== Debuginfo パッケージ ==
Packages should produce useful <code>-debuginfo</code> packages, or explicitly disable them when it is not possible to generate a useful one but rpmbuild would do it anyway.  Whenever a <code>-debuginfo</code> package is explicitly disabled, an explanation why it was done is required in the specfile.  Debuginfo packages are discussed in more detail in a separate document, [[Packaging:Debuginfo]] .
 
パッケージングするときはデバッグに役立つ <code>-debuginfo</code> パッケージも作成すべきです。又は <code>-debuginfo</code> パッケージを生成できない場合は明示的に無効にすべきです。とは言え、いずれにしても rpmbuild がそうします。<code>-debuginfo</code> パッケージが明示的に無効にするなら、spec ファイル内にその理由を説明したコメントを記載します。Debuginfo パッケージの詳細については [[Packaging:Debuginfo]] を参照してください。


{{Anchor|DevelPackages}}
{{Anchor|DevelPackages}}
== Devel パッケージ ==
== Devel パッケージ ==
If the software being packaged contains files intended solely for development, those files should be put in a -devel subpackage. The following are examples of file types which should be in -devel:
* Header files (e.g. .h files)
* Unversioned shared libraries (e.g. libfoo.so). Versioned shared libraries (e.g. libfoo.so.3, libfoo.so.3.0.0) should not be in -devel.


A good rule of thumb is if the file is used for development and not needed for the base package to run properly, it should go in -devel.
あるソフトウェアで開発に必要なファイルを含めるようにパッケージングする場合、そのようなファイルは -devel サブパッケージに含めるようにすべきです。以下に -devel に含めるべきファイル種別の例を示します。
 
* ヘッダファイル(.h ファイル)
* バージョン指定のない共有ライブラリ(libfoo.so)。バージョン指定のある共有ライブラリ(libfoo.so.3, libfoo.so.3.0.0)は -devel に含めるべきではありません。
 
分かり易い基本原則として、あるファイルが開発のために使用されてベースパッケージで実行するのに必要ないなら、そのファイルを -devel に含めるべきです。


{{Anchor|PkgconfigFiles}}
{{Anchor|PkgconfigFiles}}
=== Pkgconfig ファイル ===
=== Pkgconfig ファイル ===
The placement of pkgconfig(.pc) files depends on their usecase. Since they are almost always used for development purposes, they should be placed in a -devel package.
A reasonable exception is when the main package itself is a development tool not installed in a user runtime, e.g. gcc or gdb.


{{admon/note|EPEL difference|rpm in Fedora automatically detects dependencies on pkgconfig and between pkgconfig files.  rpm in EPEL5 and below do not have this ability and should follow the [[EPEL/GuidelinesAndPolicies#Distribution_specific_guidelines|EPEL Guidelines]].}}
pkgconfig(.pc) ファイルをどのパッケージに含めるかは、その使用方法に依存します。pkgconfig ファイルは、ほとんど開発の目的のために使用されるので、-devel パッケージに含められます。分かり易い例外としては、メインパッケージそのものがユーザ向けのランタイムをインストールしない開発向けのツールがあります。例えば、gcc や gdb になります。
 
{{admon/note|EPEL との違い|Fedora の rpm は自動的に pkgconfig と pkgconfig ファイルに関連する依存関係を検出します。EPEL5 又はそれ以下のバージョンの rpm はこの機能がないので [[EPEL/GuidelinesAndPolicies/Japanese#Distribution_specific_guidelines|EPEL ガイドライン]]に従うべきです。}}


{{Anchor|RequiringBasePackage}}
{{Anchor|RequiringBasePackage}}


== ベースパッケージの要求 ==
== ベースパッケージの要求 ==
Devel packages must require the base package using a fully versioned dependency: <code>Requires: %{name} = %{version}-%{release}</code>.
 
Usually, subpackages other than -devel should also require the base package using a fully versioned dependency.
-devel パッケージは <code>Requires: %{name} = %{version}-%{release}</code> のようにフルバージョンの依存関係を使用してベースパッケージを要求しなければなりません。普通は、-devel 以外のサブパッケージもフルバージョンの依存関係を使用してベースパッケージを要求すべきです。


{{Anchor|SharedLibraries}}
{{Anchor|SharedLibraries}}
== 共有ライブラリ ==
== 共有ライブラリ ==
Whenever possible (and feasible), Fedora Packages containing libraries should build them as shared libraries. In addition, every binary RPM package which contains shared library files (not just symlinks) in any of the dynamic linker's default paths, must call ldconfig in <code>%post</code> and <code>%postun</code>. If the package has multiple subpackages with libraries, each subpackage should also have a <code>%post/%postun</code> section that calls <code>/sbin/ldconfig</code>. An example of the correct syntax for this is:
 
できるだけ(そして適切なら)、ライブラリを含む Fedora パッケージは共有ライブラリとしてパッケージングすべきです。さらに、動的リンカの全てのデフォルトパスに存在する共有ライブラリファイル(単なるシンボリックリンクではない)を含むバイナリ RPM パッケージは <code>%post</code> や <code>%postun</code> スクリプトで <code>/sbin/ldconfig</code> コマンドを実行しなければなりません。パッケージがライブラリを含む複数のサブパッケージで構成される場合、各々のサブパッケージもまた <code>%post</code> や <code>%postun</code> スクリプトを <code>/sbin/ldconfig</code> コマンドを実行すべきです。正しい構文の例は次の通りです。
 
<pre>
<pre>
%post -p /sbin/ldconfig
%post -p /sbin/ldconfig
Line 461: Line 471:
%postun -p /sbin/ldconfig
%postun -p /sbin/ldconfig
</pre>
</pre>
Note that this specific syntax only works if <code>/sbin/ldconfig</code> is the only call in <code>%post</code> and <code>%postun</code>. If you have additional commands to run during the scriptlet, call <code>/sbin/ldconfig</code> at the beginning of the scriptlet, like this:
 
この特殊な構文は <code>/sbin/ldconfig</code> が <code>%post</code> や <code>%postun</code> で実行される場合にのみ有効であることを覚えておいてください。<code>%post</code> や <code>%postun</code> のスクリプトレットの中で他のコマンドを実行したい場合、次のように、そのスクリプトレットの最初に <code>/sbin/ldconfig</code> を実行するようにします。
 
<pre>
<pre>
%post
%post
Line 473: Line 485:


{{Anchor|StaticLibraries}}
{{Anchor|StaticLibraries}}
== 静的ライブラリのパッケージング ==
== 静的ライブラリのパッケージング ==
Packages including libraries should exclude static libs as far as possible (eg by configuring with ''--disable-static'').  Static libraries should only be included in exceptional circumstances.  Applications linking against libraries should as far as possible link against shared libraries not static versions.


Libtool archives, ''foo.la'' files, should not be included. Packages using libtool will install these by default even if you configure with ''--disable-static'', so they may need to be removed before packaging. Due to bugs in older versions of libtool or bugs in programs  that use it, there are times when it is not always possible to remove *.la files without modifying the program.  In most cases it is fairly easy to work with upstream to fix these issues.  Note that if you are updating a library in a stable release (not devel) and the package already contains *.la files, removing the *.la files should be treated as an API/ABI change -- ie: Removing them changes the interface that the library gives to the rest of the world and should not be undertaken lightly.
ライブラリを含むパッケージは、(例えば、''--disable-static''を設定して)できるだけ静的ライブラリを除外すべきです。静的ライブラリは例外的な状況や理由がある場合にのみ含めるべきです。ライブラリをリンクするアプリケーションは、できるだけ静的ライブラリではなく共有ライブラリをリンクするようにすべきです。
 
libtool のアーカイブ、つまり ''foo.la'' のようなファイルは含めるべきではありません。libtool を使用するパッケージは ''--disable-static'' を設定してもデフォルトで foo.la のようなファイルをインストールします。そのため、パッケージングする前にそのようなファイルを削除する必要があるかもしれません。libtool の古いバージョンのバグ、又は libtool を使用するプログラムのバグのために、そのプログラムを変更せずに *.la ファイルを削除できない場合があります。ほとんどのケースでは、この問題を修正するためにアップストリームで作業することが最も簡単です。安定版(開発版ではない)リリースのライブラリをアップグレードする際にパッケージが既に *.la ファイルを含んでいる場合、*.la ファイルの削除は API/ABI の変更として取り扱うべきであることに注意してください。例えば、*.la ファイルを削除することは、そのライブラリをリンクする外の世界とのインタフェースを変更します。そして、それは安易に取り掛かる作業ではありません。


{{Anchor|StaticInclusion}}
{{Anchor|StaticInclusion}}
=== 静的ライブラリのパッケージング ===
=== 静的ライブラリのパッケージング ===
* In general, packagers are strongly encouraged not to ship static libs unless a compelling reason exists.


* We want to be able to track which packages are using static libraries (so we can find which packages need to be rebuilt if a security flaw in a static library is fixed, for instance). There are two scenarios in which static libraries are packaged:
* 一般的に、パッケージャはやむを得ない理由がない限り静的ライブラリを提供しないことが強く推奨されます。
# '''Static libraries and shared libraries.''' In this case, the static libraries must be placed in a ''*-static'' subpackage. Separating the static libraries from the other development files in ''*-devel'' allow us to track this usage by checking which packages <code>BuildRequire</code> the ''*-static'' package. The intent is that whenever possible, packages will move away from using these static libraries, to the shared libraries.
 
# '''Static libraries only.''' When a package only provides static libraries you can place all the static library files in the ''*-devel'' subpackage.  When doing this you also must have a virtual Provide for the ''*-static'' package:
* 我々はどのパッケージが静的ライブラリを使用しているかを追跡できるようにしたいです(つまり、もし静的ライブラリに存在するセキュリティの不具合が修正された場合、どのパッケージをリビルドする必要があるかを見つけることができます)。どの静的ライブラリがパッケージングされているかについて2つのシナリオがあります。
# '''静的ライブラリと共有ライブラリ。'''このケースでは、静的ライブラリは ''*-static'' サブパッケージに含めなければなりません。''*-devel'' サブパッケージにある他の開発ファイルから静的ライブラリを分離することは、どのパッケージが ''*-static'' パッケージを <code>BuildRequire</code> するかをチェックすることによって、静的ライブラリと共有ライブラリを使用していることを追跡するために許容されています。その目的はこのような静的ライブラリから共有ライブラリを使用するように、可能になればいつでもパッケージを変更するためです。
# '''静的ライブラリのみ。'''あるパッケージが静的ライブラリのみを提供する場合、全ての静的ライブラリを ''*-devel'' サブパッケージに含めることができます。さらに、''*-devel'' に含めるなら、仮想的に ''*-static'' パッケージを Provide しなければなりません。
<pre>%package devel
<pre>%package devel
Provides: foo-static = %{version}-%{release}</pre>
Provides: foo-static = %{version}-%{release}</pre>


Packages which explicitly need to link against the static version must <code>BuildRequire: foo-static</code>, so that the usage can be tracked.
静的ライブラリのバージョンに対して明示的にリンクする必要があるパッケージは、その使用方法を追跡できるように <code>BuildRequire: foo-static</code> しなければなりません。


* If (and only if) a package has shared libraries which require static libraries to be functional, the static libraries can be included in the ''*-devel'' subpackage. The devel subpackage must have a virtual Provide for the ''*-static'' package, and packages dependent on it must <code>BuildRequire</code> the ''*-static'' package.
* あるパッケージが静的ライブラリを機能として要求する共有ライブラリ(のみ)を持つなら、静的ライブラリは ''*-devel'' に含めることができます。その devel パッケージは ''*-static'' パッケージのために仮想的に Provide しなければなりません。そして、devel パッケージに依存するパッケージは ''*-static'' パッケージを <code>BuildRequire</code> しなければなりません。


{{Anchor|StaticLinkage}}
{{Anchor|StaticLinkage}}
=== 実行ファイルを静的にリンクすること ===
=== 実行ファイルを静的にリンクすること ===
* Static linkage is a special exception and should be decided on a case-by-case basis.  The packager must provide rationale for linking statically, including precedences where available, to FESCO for approval.
* If you link statically against a library, add yourself to the initialcc list for the library so you can watch for any security issues or bug fixes for which you'd want to rebuild your package against a new version of the library.  Here are [[PackageMaintainers/CVSAdminProcedure|  instructions]]  for making that request.


==== FESCo へ知らせる必要のないプログラム ====
* 静的リンクは特殊な例外であり、その都度、個別に決定されるべきです。パッケージャは承認をもらうために FESCO に対して、静的リンクをする理由やその優位性も含めて提示しなければなりません、
* Programs written in OCaml do not normally link dynamically to OCaml libraries.  Because of that this requirement is waived.  (OCaml code that calls out to libraries written in C should still link dynamically to the C libraries, however.)
 
* あるライブラリに対して静的リンクするなら、そのライブラリの新バージョンに対してリビルドしたいパッケージのセキュリティ問題やバグ修正を監視できるように、そのライブラリの initialcc リストへあなたの名前を追加してください。そういったリクエストを作成するための[[PackageMaintainers/CVSAdminProcedure|手順]]があります。


* If a library you depend on '''only''' provides a static version your package can link against it provided that you <code>BuildRequire</code> the ''*-static'' subpackage. Packagers in such a situation should be aware that if a shared library becomes available, that you should adjust your package to use the shared library.
==== FESCo へ伝える必要のないプログラム ====
 
* OCaml で書かれたプログラムは通常 OCaml ライブラリを動的にリンクしません。その仕様のために静的リンクについての要件は断念します。(そうは言っても、C 言語で書かれたライブラリを呼び出す OCaml のコードは、C 言語のライブラリを動的にリンクすべきです。)
 
* あるライブラリが静的なバージョン'''のみ'''を提供するモノに依存するなら、あなたのパッケージは ''*-static'' サブパッケージを <code>BuildRequire</code> するように提供されたライブラリに対してリンクすることができます。そういった状況のパッケージャはある共有ライブラリが利用可能になったら、あなたのパッケージが共有ライブラリを使用するために調整すべきなことに気付くべきです。


==== 例外として許可されたプログラム ====
==== 例外として許可されたプログラム ====
* yaboot has permission to link statically since it's a boot loader that uses e2fsprogs-libs to read the filesystem
 
* yaboot はファイルシステムを読むために e2fsprogs-libs を使用するブートローダなので静的リンクすることができます。


{{Anchor|SystemLibraryDuplication}}
{{Anchor|SystemLibraryDuplication}}
Line 509: Line 528:
== システムライブラリの重複 ==
== システムライブラリの重複 ==


A package should not include or build against a local copy of a library that exists on a system. The package should be patched to use the system libraries.  This prevents old bugs and security holes from living on after the core system libraries have been fixed.  More rationale for this is on the [[Packaging:No Bundled Libraries|No Bundled Libraries]] page.
システムに存在するライブラリのローカルコピーをパッケージに含めてビルドすべきではありません。そういったパッケージはシステムライブラリを使用するように修正すべきです。こうすることにより、システムのコアライブラリが修正された後でも古いバグやセキュリティホールが残り続けるのを防ぐことができます。パッケージによってはこの内容に対する例外が許可されるかもしれません。詳細については[[Packaging:No Bundled Libraries|一括りにまとめないライブラリ]]の、関連内容や例外が許可されるためのプロセス、あなたのパッケージを一括りにまとめるならその要求仕様を参照してください。


{{Anchor|Rpath}}
{{Anchor|Rpath}}
== Rpath に気を付けること ==
Sometimes, code will hardcode specific library paths when linking binaries (using the -rpath or -R flag). This is commonly referred to as an rpath. Normally, the dynamic linker and loader (ld.so) resolve the executable's dependencies on shared libraries and load what is required. However, when -rpath or -R is used, the location information is then hardcoded into the binary and is examined by ld.so in the beginning of the execution. Since the Linux dynamic linker is usually smarter than a hardcoded path, we usually do not permit the use of rpath in Fedora.


There is a tool called ''check-rpaths'' which is included in the ''rpmdevtools'' package. It is a good idea to add it to the ''<code>%__arch_install_post</code>'' macro in your ''<code>~/.rpmmacros</code>'' config file:
== Rpath に注意する ==
 
稀に、(-rpath 又は -R フラッグを使用して)バイナリをリンクするときにコード内に特定のライブラリパスがハードコーディングされます。これは一般的に rpath として参照されます。通常は、動的リンカやローダー(ld.so)が共有ライブラリの実行可能な依存関係を解決して、必要とされるライブラリをロードします。しかし、-rpath 又は -R が使用された場合、そのパス情報はバイナリ内にハードコーディングされていて実行時に ld.so によって調べられます。Linux 動的リンカはハードコーディングされたパスよりも普通は利口に動作するので、Fedora では rpath の使用を通常は許可していません。
 
''rpmdevtools'' パッケージに含まれる ''check-rpaths'' というツールがあります。''<code>~/.rpmmacros</code>'' 設定ファイルの ''<code>%__arch_install_post</code>'' マクロに ''check-rpaths'' を追加すると良いでしょう。
 
<pre>
<pre>
%__arch_install_post            \
%__arch_install_post            \
Line 521: Line 543:
/usr/lib/rpm/check-buildroot
/usr/lib/rpm/check-buildroot
</pre>
</pre>
 
''check-rpaths'' が実行されると次のように出力されるかもしれません。
When ''check-rpaths'' is run, you might see output like this:
<pre>
<pre>
ERROR  0001: file '/usr/bin/xapian-tcpsrv' contains a standard rpath '/usr/lib64' in [/usr/lib64]  
ERROR  0001: file '/usr/bin/xapian-tcpsrv' contains a standard rpath '/usr/lib64' in [/usr/lib64]  
</pre>
</pre>


Any rpath flagged by check-rpaths '''MUST''' be removed.
check-rpaths が検出した全ての rpath は削除 '''しなければなりません'''。


{{Anchor|AcceptableRpath}}
{{Anchor|AcceptableRpath}}
=== 内部ライブラリのための Rpath ===
=== 内部ライブラリのための Rpath ===


When a program installs internal libraries they are often not installed in the system path.  These internal libraries are only used for the programs that are present in the package (for example, to factor out code that's common to the executables).  These libraries are not intended for use outside of the package.  When this occurs, it is acceptable for the programs within the package to use an rpath to find these libraries.
あるプログラムが内部で使用するライブラリをインストールするとき、大抵はシステムパスにインストールしません。これらの内部ライブラリはパッケージ内のそのプログラムのため(例えば、共通で実行されるコードを取り除くため)にのみ使用されます。また内部ライブラリはパッケージの外部で使用することを想定していません。こういった場合、内部ライブラリを見つけるために rpath を使用してパッケージ内にそのプログラムを含める目的なら許容されます。


Example:
例:
<pre>
<pre>
# Internal libraries for myapp are present in:
# Internal libraries for myapp are present in:
Line 546: Line 567:
</pre>
</pre>


{{admon/tip|Non-Internal Libraries|When programs outside of the package are supposed to link against the library, it is better to use the [[#AlternativeRpath| Alternative to Rpath]] or simply move the libraries into %{_libdir} instead.  That way the dynamic linker can find the libraries without having to link all the programs with an rpath.}}
{{admon/tip|非内部ライブラリ|あるパッケージ外部のプログラムがライブラリに対してリンクすることを想定するとき、[[#AlternativeRpath| Rpath の代替方法]]、又は単に %{_libdir} 内へライブラリを移動するのが良い方法です。そうすれば、rpath で全てのプログラムにリンクせずに動的リンカがライブラリを見つけることができます。}}


{{Anchor|AlternativeRpath}}
{{Anchor|AlternativeRpath}}
=== Rpath に代わるもの ===
=== Rpath の代替方法 ===
Often, rpath is used because a binary is looking for libraries in a non-standard location (standard locations are /lib, /usr/lib, /lib64, /usr/lib64). If you are storing a library in a non-standard location (e.g. /usr/lib/foo/), you should include a custom config file in /etc/ld.so.conf.d/. For example, if I was putting 32 bit libraries of libfoo in /usr/lib/foo, I would want to make a file called "foo32.conf" in /etc/ld.so.conf.d/, which contained the following:
 
あるバイナリが非標準パス(標準パスは /lib, /usr/lib, /lib64, /usr/lib64 です)に存在するライブラリを探すのに rpath がよく使用されます。ライブラリを非標準パス(例えば、/usr/lib/foo/)に格納する場合、/etc/ld.so.conf.d/ にその設定ファイルを含めるべきです。例えば、/usr/lib/foo に libfoo の 32bit ライブラリが存在する場合、/etc/ld.so.conf.d/ に "foo32.conf" というファイルを作成して次のように設定します。
<pre>
<pre>
/usr/lib/foo
/usr/lib/foo
</pre>
</pre>
Make sure that you also make a 64bit version of this file (e.g. foo64.conf) as well (unless the package is disabled for 64bit architectures, of course).
同様に 64bit バージョンのファイル(例えば、foo64.conf)を作成することも確認してください(もちろんパッケージが 64bit アーキテクチャをサポートする場合です)。


{{Anchor|RemovingRpath}}
{{Anchor|RemovingRpath}}
=== Rpath を削除すること ===
=== Rpath を削除する ===


There are several different ways to fix the rpath issue:
rpath の問題を修正する方法は幾つかあります。


* If the application uses configure, try passing the ''--disable-rpath'' flag to configure.
* 対象アプリケーションが configure を使用するなら、オプションに ''--disable-rpath'' を与えるようにしてください。
* If the application uses a local copy of libtool, add the following lines to the spec after %configure:
* 対象アプリケーションが libtool のローカルコピーを使用するなら、spec ファイルの %configure の後に次のように設定してください。
<pre>
<pre>
%configure
%configure
Line 568: Line 590:
sed -i 's|^runpath_var=LD_RUN_PATH|runpath_var=DIE_RPATH_DIE|g' libtool
sed -i 's|^runpath_var=LD_RUN_PATH|runpath_var=DIE_RPATH_DIE|g' libtool
</pre>
</pre>
* Sometimes, the code/Makefiles can be patched to remove the ''-rpath'' or ''-R'' flag from being called. This is not always easy or sane to do, however.
* 稀に、コード/Makefile で ''-rpath'' 又は ''-R'' フラッグが与えられないように取り除くパッチが適用されます。しかし、これは簡単ではなく、適切な方法でもありません。
* As a last resort, Fedora has a package called ''chrpath''. When this package is installed, you can run <code>chrpath --delete</code> on the files which contain rpaths. So, in our earlier example, we'd run:
* 最終手段として、Fedora には ''chrpath'' というパッケージがあります。このパッケージがインストールされる場合、rpath を含むファイルに対して <code>chrpath --delete</code> を実行することができます。先に説明した例であれば次のように実行します。
<pre>
<pre>
chrpath --delete $RPM_BUILD_ROOT%{_bindir}/xapian-tcpsrv
chrpath --delete $RPM_BUILD_ROOT%{_bindir}/xapian-tcpsrv
</pre>
</pre>
Make sure that you remember to add a '''BuildRequires: chrpath''' if you end up using this method.
最終的にこの方法を使用することに決めたら '''BuildRequires: chrpath''' を spec ファイルに追加することを忘れないように注意してください。


{{Anchor|Config}}
{{Anchor|Config}}
== 設定ファイル ==
== 設定ファイル ==


Line 595: Line 618:
== デスクトップファイル ==
== デスクトップファイル ==


If a package contains a GUI application, then it needs to also include a properly installed .desktop file.  For the purposes of these guidelines, a GUI application is defined as any application which draws an X window and runs from within that window.  Installed .desktop files MUST follow the [http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html desktop-entry-spec] , paying particular attention to validating correct usage of Name, GenericName, [http://standards.freedesktop.org/menu-spec/latest/apa.html Categories] ,
パッケージが GUI アプリケーションを含むなら、適切にインストールされる .desktop ファイルも含める必要があります。このガイドラインの対象となる GUI アプリケーションとは X ウィンドウを描画して、そのウィンドウ内で実行される全てのアプリケーションのことです。インストールされる .desktop ファイルは、Name, GenericName, [http://standards.freedesktop.org/menu-spec/latest/apa.html Categories], [http://www.freedesktop.org/Standards/startup-notification-spec StartupNotify] エントリの正しい用途を検証することに十分注意を払いながら、[http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html desktop-entry-spec] に従わなければなりません。
[http://www.freedesktop.org/Standards/startup-notification-spec StartupNotify]
entries.


=== アイコンタグとデスクトップファイル ===
=== アイコンタグとデスクトップファイル ===
The icon tag can be specified in two ways:


* Full path to specific icon file:
アイコンタグの指定方法は2通りあります。
 
* フルパス指定のアイコンファイル
<code> Icon=/usr/share/pixmaps/comical.png </code>
<code> Icon=/usr/share/pixmaps/comical.png </code>


* Short name without file extension:
* 拡張子なしの短縮名
<code> Icon=comical </code>
<code> Icon=comical </code>


The short name without file extension is preferred, because it allows for icon theming (it assumes .png by default, then tries .svg and finally .xpm), but either method is acceptable.
アイコンテーミング(デフォルトは .png、次に .svg、最後 .xpm と仮定する)を許容するので拡張子なしの短縮名の方が推奨されます。とは言え、どちらの方法でも良いです。


=== .desktop ファイルの作成 ===
=== .desktop ファイルの作成 ===
If the package doesn't already include and install its own .desktop file, you need to make your own. You can do this by including a .desktop file you create as a Source: (e.g. Source3: %{name}.desktop) or generating it in the spec file. Here are the contents of a sample .desktop file (comical.desktop):
 
そのパッケージが自身の .desktop ファイルを持っていなくてインストールしないなら、.desktop ファイルを作成する必要があります。Source(例えば、Source3: %{name}.desktop)として作成した .desktop ファイルを含める、又は spec ファイル内で .desktop ファイルを生成することができます。例えば、.desktop ファイル(comical.desktop)のサンプルは次のようになります。


<pre>
<pre>
Line 626: Line 649:


=== desktop-file-install の使用方法 ===
=== desktop-file-install の使用方法 ===
It is not simply enough to just include the .desktop file in the package, one MUST run <code>desktop-file-install</code> OR <code>desktop-file-validate</code> in <code>%install</code> (and have <code>BuildRequires: desktop-file-utils</code>), to help ensure .desktop file safety and spec-compliance. <code>desktop-file-install</code> MUST be used if the package does not install the file or there are changes desired to the .desktop file (such as add/removing categories, etc). <code>desktop-file-validate</code> MAY be used instead if the .desktop file's content/location does not need modification.  Here are some examples of
 
usage:
ただパッケージに .desktop ファイルを含めるのみだと十分ではありません。spec ファイルの仕様に準拠した安全な .desktop ファイルを保証するために <code>%install</code> セクションで <code>desktop-file-install</code> 又は <code>desktop-file-validate</code> を実行しなければなりません(そして <code>BuildRequires: desktop-file-utils</code> を設定する)。パッケージが .desktop ファイルをインストールしない、又は .desktop ファイルに対して(カテゴリを追加/削除する等の)変更がある場合、<code>desktop-file-install</code> が使用されなければなりません。.desktop ファイルの内容/場所を変更しない場合、<code>desktop-file-validate</code> を使用しても構いません。ここに使用例のサンプルがあります。


<pre>
<pre>
Line 647: Line 670:
</pre>
</pre>


* For new packages, do not apply a vendor tag to desktop files. Existing packages that use a vendor tag must continue to do so for the life of the package. This is mostly for the sake of menu-editing (which bases off of .desktop file/path names).
* 新しいパッケージには、vendor タグを .desktop ファイルへ適用してはいけません。vendor タグを使用する既存パッケージは、パッケージのライフサイクルのために継続して使用しなければなりません。この理由はほとんど (.desktop ファイル/パス名をベースとする)menu-editing のためです。


{{Anchor|macros}}
{{Anchor|macros}}


== マクロ ==
== マクロ ==
Use macros instead of hard-coded directory names (see [[Packaging:RPMMacros]] ).


Having macros in a Source: or Patch: line is a matter of style.  Some people enjoy the ready readability of a source line without macros. Others prefer the ease of updating for new versions when macros are used.  In all cases, remember to be consistent in your spec file and verify that the URLs you list are valid.  spectool (from the rpmdevtools package) can aid you in checking that whether the URL contains macros or not.
ハードコーディングされたディレクトリ名の代わりにマクロ([[Packaging:RPMMacros]] を参照)を使用してください。
 
Source: 又は Patch: 行の中にマクロを使用することはスタイルの問題です。マクロなしの方が Source: の可読性が良いと考える人がいます。一方、人によってはマクロを使用すると新しいバージョンへアップデートが簡単なので好む人もいます。全てのケースにおいて、spec ファイル内で統一することと、記載した URL が有効かを検証することを覚えておいてください。spectool(rpmdevtools パッケージに含まれる)は URL がマクロを含むかどうかをチェックするのに役立ちます。
 
もしマクロを含むときに実際の文字列を調べる必要があるなら、rpm コマンドを使用することができます。例えば、実際の Source: の値を調べるには次のように実行します。


If you need to determine the actual string when it contains macros, you can use rpm. For example, to determine the actual Source: value, you can run:
<pre>
<pre>
rpm -q --specfile foo.spec --qf "$(grep -i ^Source foo.spec)\n"
rpm -q --specfile foo.spec --qf "$(grep -i ^Source foo.spec)\n"
Line 662: Line 687:


{{Anchor|UsingBuildRootOptFlags}}
{{Anchor|UsingBuildRootOptFlags}}
=== %{buildroot} と %{optflags} vs $RPM_BUILD_ROOT と $RPM_OPT_FLAGS を使用すること ===
=== %{buildroot} と %{optflags} vs $RPM_BUILD_ROOT と $RPM_OPT_FLAGS の使用 ===
There are two styles of defining the rpm Build Root and Optimization Flags in a spec file:
 
spec ファイル内で rpm の Build Root と最適化フラグを定義する2つのスタイルがあります。


{| border="1"
{| border="1"
Line 674: Line 700:
|}
|}


There is very little value in choosing one style over the other, since they will resolve to the same values in all scenarios. You should pick a style and use it consistently throughout your packaging.
全てのシナリオで同じ値を取得するので、どちらのスタイルを選択するかについてはどちらでも構いません。一方のスタイルを選択して、パッケージングする際は統一してそのスタイルを使用すべきです。


Mixing the two styles, while valid, is bad from a QA and usability point of view, and should not be done in Fedora packages.
2つのスタイルを混在させることは、正常には動作しますが、QA やユーザビリティの視点から悪いことです。そして、Fedora パッケージでそれをしてはいけません。


{{Anchor|MakeInstall}}
{{Anchor|MakeInstall}}
=== %makeinstall マクロを使用しない理由 ===
=== %makeinstall マクロを使用しない理由 ===
Fedora's RPM includes a <code>%makeinstall</code> macro but it must '''NOT''' be used when make install DESTDIR=%{buildroot} works. %makeinstall is a kludge that can work with Makefiles that don't make use of the DESTDIR variable but it has the following potential issues:
* <code>%makeinstall</code> overrides a set of Make variables during "make install" and prepends the %{buildroot} path. I.e. it performs make prefix="%{buildroot}%{_prefix}" libdir="%{buildroot}%{_libdir} ...".
* It is error-prone and can have unexpected effects when run against less than perfect Makefiles, e.g. the buildroot path may be included in installed files where variables are substituted at install-time.
* It can trigger unnecessary and wrong rebuilds when executing "make install", since the Make variables have different values compared with the %build section.
* If a package contains libtool archives, it can cause broken *.la files to be installed.


Instead, Fedora packages should use: <code>make DESTDIR=%{buildroot} install</code> or <code>make DESTDIR=$RPM_BUILD_ROOT install</code>
Fedora の RPM は <code>%makeinstall</code> マクロを含みますが、それは make install DESTDIR=%{buildroot} が動作するときに使用しては '''いけません'''。%makeinstall は DESTDIR の値を利用しない Makefile で動作する一時解決的な方法ですが、%makeinstall を使用することで次の潜在的問題があります。
 
* <code>%makeinstall</code> は "make install" の最中に Make 変数セットを上書きして %{buildroot} パスを先頭に追加します。つまり、それは make prefix="%{buildroot}%{_prefix}" libdir="%{buildroot}%{_libdir} ..." を実行することになります。
* それはエラーになり易い傾向があり、完全な Makefile ではないものに対して実行すると予期せぬ結果を招きます。例えば、変数がインストール時に置き換えると buildroot パスはインストールされたファイルに含まれるかもしれません。
* "make install" を実行するときに、違う値を持った Make 変数が %build セクションで評価されるので、不必要な誤ったリビルドを引き起こすきっかけになります。
* あるパッケージが libtool アーカイブを含む場合、壊れた *.la ファイルをインストールしてしまうことを引き起こします。
 
代替方法として、Fedora パッケージは <code>make DESTDIR=%{buildroot} install</code> 又は <code>make DESTDIR=$RPM_BUILD_ROOT install</code> を使用すべきです。


=== ソース RPM ビルド時間のマクロ ===
=== ソース RPM ビルド時間のマクロ ===
All macros in <code>Summary:</code> and <code>%description</code> need to be expandable at srpm buildtime.  Because SRPMs are built without the package's BuildRequires installed, depending on macros defined outside of the spec file can easily lead to the unexpanded macros showing up in the built SRPM.  One way to check is to create a minimal chroot and build the srpm:
 
<code>Summary:</code> と <code>%description</code> にある全てのマクロは SRPM のビルド時に展開される必要があります。SRPM は、そのパッケージの BuildRequires をインストールせずにビルドされるので、spec ファイルの外側で定義されたマクロに依存することは SRPM をビルドした結果として簡単に展開できないマクロが表示されることになります。1つの方法として、最小限の chroot を作成して SRPM をビルドすることでチェックすることができます。


<pre>
<pre>
Line 700: Line 729:
rpm -qpiv /builddir/build/SRPMS/[SRPM]
rpm -qpiv /builddir/build/SRPMS/[SRPM]
</pre>
</pre>
Check the <code>rpm</code> output for unexpanded macros (<code>%{foo}</code>) or missing information (when<code>%{?foo}</code> is expanded to the empty string).  Even easier is to simply avoid macros in <code>Summary:</code> and <code>%description</code> unless they are defined in the current spec file.


== %define よりも優先される %global ==
展開できないマクロ(<code>%{foo}</code>)、又は消えてしまった情報(when<code>%{?foo}</code> は空文字列に展開されます)がないかについて <code>rpm</code> の出力をチェックしてください。spec ファイルの <code>Summary:</code> と <code>%description</code> でマクロを定義しないことがより簡単な解決方法です。
 
=== 間違った %_sourcedir の使用方法 ===
 
Source# として箇条書きのファイルを使用するパッケージは <code>Source#</code> マクロ名でそういったファイルを参照しなければなりません。さらにそういったファイルを参照するために <code>$RPM_SOURCE_DIR</code> 又は <code>%{sourcedir}</code> を使用してはいけません。詳細は [[Packaging:RPM_Source_Dir]] を参照してください。


Use <code>%global</code> instead of <code>%define</code>, unless you really need only locally defined submacros within other macro definitions (a very rare case).
== %define よりも %global を優先的に使用する ==


Rationale: The two macro defining statements behave the same when they are a the top level of rpm's nesting level.
他のマクロ定義内にローカルに定義されたサブマクロが必要でない限り(とても稀なケースです)、<code>%define</code> の代わりに <code>%global</code> を使用してください。


But when they are used in nested macro expansions (like in <code> %{!?foo: ... } </code> constructs, <code>%define</code> theoretically only lasts until the end brace (local scope), while <code>%global</code> definitions have global scope.
その理由は、ステートメントを定義する2つのマクロは rpm のネストされたレベルのトップレベルにある場合も同じように動作するからです。


{{admon/note||In Fedora 12 and earlier, a minor bug in rpm caused the local macro definition to not be garbage collected unless other events forced rpm to. So the bug is seldom triggered but when it is it is difficult to diagnose the issue. Using <code>%global</code> by default helps to avoid creation of new latent bugs. [https://www.redhat.com/archives/fedora-devel-list/2010-January/msg00093.html Bugfix description]}}
しかし、<code> %{!?foo: ... } </code> のような構造のネストされたマクロ拡張が使用される場合、<code>%define</code> は論理的にローカルスコープの範囲内のみその定義が有効になるのに対して、<code>%global</code> 定義はグローバルスコープを持ちます。
 
{{admon/note||Fedora12 やそれ以下のリリースでは、rpm に小さなバグがあり、ローカルのマクロ定義は他のイベントが rpm に対して強制的に行わない限りガベージコレクションされません。そのため、そのバグは滅多に発生しませんが、発生するとローカルのマクロ定義の問題の原因を突き止めるのはとても難しいです。<code>%global</code> をデフォルトとして使用することで新たな潜在的なバグを発生させないことに役立ちます。[https://www.redhat.com/archives/fedora-devel-list/2010-January/msg00093.html バグ修正内容]}}


{{Anchor|locales}}
{{Anchor|locales}}


== ローカルファイルを扱うこと ==
== ロケールファイルを扱う ==
 
パッケージが翻訳ファイルを含むなら、


If the package includes translations, add
<pre>
<pre>
BuildRequires: gettext
BuildRequires: gettext
</pre>
</pre>
If you don't, your package could fail to generate translation files in the buildroot.


Fedora includes an rpm macro called <code>%find_lang</code>. This macro will locate all of the locale files that belong to your package (by name), and put this list in a file. You can then use that file to include all of the locales. <code>%find_lang</code> should be run in the %install section of your spec file, after all of the files have been installed into the buildroot. The correct syntax for <code>%find_lang</code> is usually:
を追加してください。そうしないと、そのパッケージは buildroot で翻訳ファイルを生成する際にエラーとなるでしょう。
 
Fedora には <code>%find_lang</code> という rpm マクロがあります。このマクロは(名前から)そのパッケージに属する全てのロケールファイルを配置します。そして、あるファイル内にロケールファイルのリストを保持します。それから、全てのロケールを含めるためにそのファイルを使用することができます。<code>%find_lang</code> は buildroot へ全てのファイルがインストールされた後、spec ファイルの %install セクションで実行されます。<code>%find_lang</code> の正しい構文は、通常は次の通りです。
 
<pre>
<pre>
%find_lang %{name}
%find_lang %{name}
</pre>
</pre>
In some cases, the application may use a different "name" for its locales. You may have to look at the locale files and see what they are named. If they are named <code>myapp.mo</code>, then you will need to pass <code>myapp</code> to <code>%find_lang</code> instead of <code>%{name</code>}.
 
After <code>%find_lang</code> is run, it will generate a file in the active directory (by default, the top level of the source dir). This file will be named based on what you passed as the option to the <code>%find_lang</code> macro. Usually, it will be named <code>%{name}.lang</code>. You should then use this file in the <code>%files</code> list to include the locales detected by <code>%find_lang</code>. To do this, you should include it with the -f parameter to <code>%files</code>.
アプリケーションによっては、そのロケールに違う "名前" を使用するかもしれません。そのため、ロケールファイルを探して、どのような名前が使用されているかを確認する必要があるかもしれません。もし <code>myapp.mo</code> という名前だったら、<code>%{name</code>} の代わりに <code>%find_lang</code> へ <code>myapp</code> をオプションとして渡す必要があります。
<code>%find_lang</code> の実行後、ロケールファイルのリストを保持したファイルをアクティブなディレクトリ(デフォルトでは、ソースディレクトリのトップディレクトリ)に生成するでしょう。このファイルは <code>%find_lang</code> マクロへオプションとして渡された名前に基づきます。通常は <code>%{name}.lang</code> という名前になります。
このファイルを使用して <code>%find_lang</code> が検出したロケールファイルを <code>%files</code> リストへ含めます。こうするには、<code>%files</code> で -f パラメータと共に <code>{name}.lang</code> を指定します。
 
<pre>
<pre>
%files -f %{name}.lang
%files -f %{name}.lang
Line 734: Line 774:
...
...
</pre>
</pre>
If you are already using the -f parameter for the <code>%files</code> section where the locales should live, just append the contents of <code>%{name}.lang</code> to the end of the file that you are already using with -f. (Note that only one file may be used with <code>%files -f</code>.)


Here is an example of proper usage of <code>%find_lang</code>, in <code>foo.spec</code>:
もしロケールが存在して <code>%files</code> セクションに -f パラメータを既に指定しているなら、<code>%{name}.lang</code> のコンテンツを -f を指定しているファイルの最後へ単純に追加してください。(もしかすると1ファイルしか <code>%files -f</code> に渡せないかもしれません)
 
ここに <code>foo.spec</code> の <code>%find_lang</code> の適切な使用例があります。


<pre>
<pre>
Line 766: Line 807:


{{Anchor|whyfindlang}}
{{Anchor|whyfindlang}}
=== %find_lang を使用する必要がある理由 ===
=== %find_lang を使用しなければならない理由 ===


Using <code>%find_lang</code> helps keep the spec file simple, and helps avoid several other packaging mistakes.
<code>%find_lang</code> を使用することは spec ファイルをシンプルにすることに役立ちます。そして、幾つかの理由でパッケージングの失敗を防ぐことにも役立ちます。


* Packages that use <code>%{_datadir}/*</code> to grab all the locale files in one line also grab ownership of the locale directories, which is not permitted.
* 1行で全てのロケールファイルを表すために <code>%{_datadir}/*</code> を使用するパッケージは、ロケールディレクトリの所有権も持つことになりますが、それは許可されていません。
* Most packages that have locales have lots of locales. Using <code>%find_lang</code> is much easier in the spec file than having to do:
* ロケールを持つ大半のパッケージは大量のロケールファイルを持っています。<code>%find_lang</code> を使用する方が spec ファイルに次のように記述よりもずっと簡単です。
<pre>
<pre>
%{_datadir}/locale/ar/LC_MESSAGES/%{name}.mo
%{_datadir}/locale/ar/LC_MESSAGES/%{name}.mo
Line 780: Line 821:
...
...
</pre>
</pre>
* As new locale files appear in later package revisions, <code>%find_lang</code> will automatically include them when it is run, preventing you from having to update the spec any more than is necessary.
* パッケージのバージョンが上がり新たなロケールファイルが追加されると、<code>%find_lang</code> は実行時に自動的に追加されたロケールファイルを含めるようになります。必要以上にロケールに関する内容で spec ファイルを更新する必要はありません。


Keep in mind that usage of <code>%find_lang</code> in packages containing locales is a MUST.
ロケールを含むパッケージでは <code>%find_lang</code> を使用しなければならないことを忘れないでください。


{{Anchor|Timestamps}}
{{Anchor|Timestamps}}


== タイムスタンプ ==
== タイムスタンプ ==
When adding file copying commands in the spec file, consider using a command that preserves the files' timestamps, eg. <code>cp -p</code> or <code>install -p</code>.


When downloading sources, patches etc, consider using a client that preserves the upstream timestamps.  For example <code>wget -N</code> or <code>curl -R</code>.  To make the change global for wget, add this to your <code>~/.wgetrc</code>: <code>timestamping = on</code>, and for curl, add to your <code>~/.curlrc</code>: <code>-R</code>.
spec ファイルでファイルをコピーするコマンドを追加するとき、ファイルのタイムスタンプを保持するコマンドを使用するように考慮してください。例えば、<code>cp -p</code> か <code>install -p</code> になります。
 
ソースやパッチ等をダウンロードするときは、アップストリームのタイムスタンプを保持するダウンロードツールを使用するように考慮してください。例えば、<code>wget -N</code> か <code>curl -R</code> になります。wget の設定をグローバルに有効にするには、<code>~/.wgetrc</code> に <code>timestamping = on</code> を追加してください。同様に、curl には <code>~/.curlrc</code> に <code>-R</code> を追加してください。


{{Anchor|parallelmake}}
{{Anchor|parallelmake}}
== 並列に make ==
 
Whenever possible, invocations of <code>make</code> should be done as
== 並行 make ==
 
できるだけ <code>make</code> の起動は次のようにすべきです。
 
<pre>
<pre>
make %{?_smp_mflags}
make %{?_smp_mflags}
</pre>
</pre>
This generally speeds up builds and especially on SMP machines.


Do make sure, however, that the package builds cleanly this way as some make files do not support parallel building. Therefore you should consider adding
これは一般的にビルド処理が速くなります。特に SMP マシン上で速くなります。
 
しかし、並行ビルドをサポートしない make ファイルもあるのでパッケージがこの方法で効率良くビルドできるかを確認してください。そのため、<code>~/.rpmmacros</code> ファイルに
<pre>
<pre>
%_smp_mflags -j3
%_smp_mflags -j3
</pre>
</pre>
to your <code>~/.rpmmacros</code> file -- even on UP machines -- as this will expose most of these errors.
を追加する必要があるかを考慮すべきです。UP マシン上では、この設定がエラーの大半になります。


{{Anchor|Scriptlets}}
{{Anchor|Scriptlets}}
== スクリプトレット ==
== スクリプトレット ==
Great care should be taken when using scriptlets in Fedora packages. If scriptlets are used, those scriptlets must be sane. Some common scriptlets are documented here: [[Packaging:ScriptletSnippets]].
 
Fedora パッケージ内でスクリプトレットを使用する場合、本当に慎重になって扱うべきです。スクリプトレットが使用されるとき、それは適切に動作するものでなければなりません。[[Packaging:ScriptletSnippets]] に一般的なスクリプトレットについて記載されています。


{{Anchor|reqprepost}}
{{Anchor|reqprepost}}
=== スクリプトレットの要求仕様 ===
=== スクリプトレットの要求仕様 ===
Do not use the <code>Requires(pre,post)</code> style notation for scriptlet dependencies, because of two bugs in RPM. Instead, they should be split like this:
 
スクリプトレットの依存関係のために <code>Requires(pre,post)</code> スタイルの記述方法を使用しないでください。というのは RPM に2つのバグがあるからです。その代わりに、次のように分割して記述すべきです。
 
<pre>
<pre>
Requires(pre): ...
Requires(pre): ...
Requires(post): ...
Requires(post): ...
</pre>
</pre>
For more information, see [http://www.redhat.com/archives/fedora-devel-list/2004-April/msg00674.html www.redhat.com] .
 
詳細は [http://www.redhat.com/archives/fedora-devel-list/2004-April/msg00674.html www.redhat.com] を参照してください。


{{Anchor|ScriptletConditionals}}
{{Anchor|ScriptletConditionals}}
=== 特定状況でのみのスクリプトレットの実行 ===
=== 特定状況でのみのスクリプトレットの実行 ===
When the rpm command executes the scriptlets in a package it indicates if the action preformed is an install, erase, upgrade or reinstall by passing an integer argument to the script in question according to the following:
 
rpm コマンドがあるパッケージのスクリプトレットを実行するとき、その動作がインストール、削除、アップグレード、又は再インストールのどれかで、次のようにスクリプトに対して与えられる整数の引数が変わります。
 
<pre>
<pre>
           install  erase  upgrade  reinstall
           install  erase  upgrade  reinstall
Line 828: Line 881:
%postun      -        0        1        -
%postun      -        0        1        -
</pre>
</pre>
This means that for example a package that installs an init script with the <code>chkconfig</code> command should uninstall it only on erase and not upgrade with the following snippet:
 
例えば、<code>chkconfig</code> コマンドで初期化スクリプトをインストールするパッケージは、アップグレードではなく削除のみを行う場合は次のようなスニペットでアンインストールすべきです。
 
<pre>
<pre>
%preun
%preun
Line 835: Line 890:
fi
fi
</pre>
</pre>
See also <code>/usr/share/doc/rpm-*/triggers</code>, which gives a more formal, generalized definition about the integer value(s) passed to various scripts.
 
また様々なスクリプトに渡される整数値について、公式の、汎用的な定義は <code>/usr/share/doc/rpm-*/triggers</code> も参照してください。


{{Anchor|SciptletsWriteDirs}}
{{Anchor|SciptletsWriteDirs}}
=== 特定ディレクトリの書き込みのみが許可されているスクリプトレット ===
=== 特定ディレクトリに書き込みのみが許可されているスクリプトレット ===
Build scripts of packages (%prep, %build, %install, %check and %clean) may only alter files (create, modify, delete) under %{buildroot}, %{_builddir} and valid temporary locations like /tmp, /var/tmp (or $TMPDIR or %{_tmppath} as set by the rpmbuild process) according to the following matrix
 
次の表にある /tmp, /var/tmp (又は rpmbuild プロセスによってセットされる $TMPDIR や %{_tmppath})といった有効な一時ファイル置き場や %{buildroot}, %{_builddir} 配下にあるファイル(作成、変更、削除)のみを変更するパッケージのスクリプト(%prep, %build, %install, %check と %clean)を構築してください。


{| border="1"
{| border="1"
Line 856: Line 913:
|}
|}


Further clarification: That should hold true irrespective of the builder's uid.
厳密に補足すると、ビルドを実行するユーザの uid に関係なくこの表の通りになるようにすべきです。


{{Anchor|ConditionalDependencies}}
{{Anchor|ConditionalDependencies}}
== 条件付きの依存関係 ==
== 条件付きの依存関係 ==
If the spec file contains conditional dependencies selected based on presence of optional <code>--with(out) foo</code> arguments to <code>rpmbuild</code>, build the source RPM to be submitted with the default options, ie. so that none of these arguments are present in the <code>rpmbuild</code> command line.  The reason is that those requirements get "serialized" into the resulting source RPM, ie. the conditionals no longer apply.
 
<code>rpmbuild</code> への <code>--with(out) foo</code> のオプション引数が存在して、条件によって選択される依存関係を spec ファイルに含む場合、デフォルトオプション、つまり、<code>rpmbuild</code> のコマンドラインにこのような引数が与えずに実行されるようにソース RPM をビルドするようにしてください。その理由はそういった要件は結果的にはソース RPM の中に "含めるようにする" からです。つまり、spec ファイルの条件で適用するものではありません。


{{Anchor|SeparateUserAccounts}}
{{Anchor|SeparateUserAccounts}}
== ユーザアカウントを分離したパッケージのビルド ==
When building software, which you have not conducted a full security-audit on, protect sensitive data, such as your GPG private key, in a separate user account.


The same applies to reviewers/testers. Rebuild src.rpms in a separate account which does not have access to any sensitive data.
== 別のユーザアカウントでパッケージをビルドする ==
 
あなたが完全なセキュリティ監査を実施しない状態でソフトウェアをビルドする場合、別のユーザアカウントを使用して自身の機密情報を保護してください。機密情報とは、例えば、あなたの GPG 秘密鍵のような情報を指します。
 
機密情報の保護についてはレビューアやテスターにも当てはまります。いかなる機密情報にもアクセスできない別のユーザアカウントで src.rpms をリビルドしてください。


{{Anchor|RelocatablePackages}}
{{Anchor|RelocatablePackages}}
== 再配置可能なパッケージ ==
== 再配置可能なパッケージ ==
The use of RPM's facility for generating relocatable packages is strongly discouraged.  It is difficult to make work properly, impossible to use from the installer or from yum, and not generally necessary if other packaging guidelines are followed. However, in the unlikely event that you have a good reason to make a package relocatable, you MUST state this intent and reasoning in the request for package review.


再配置可能なパッケージを生成するために RPM の仕組みを利用しようと思うと本当にがっかりします。適切に動作させるのが難しく、yum 又はインストーラーから使用するのは不可能であり、他のパッケージガイドラインに従うなら一般的には必要ないからです。到底起こりそうもないことですが、パッケージを再配置可能な状態にするに足る理由があるなら、パッケージレビューでその要件の意図と理由をはっきりと説明しなければなりません。


{{Anchor|CodeVsContent}}
{{Anchor|CodeVsContent}}
== コード Vs コンテンツ ==
== コード Vs コンテンツ ==
It is important to make distinction between computer executable code and content.
While code is permitted (assuming, of course, that it has an open source compatible license, is not legally questionable, etc.), only some kinds of content are permissable.


The rule is this:
コンピュータの実行可能なコードとコンテンツを区別するのは重要です。(もちろん、オープンソース互換ライセンスであり、法的な問題がない等を前提として)コードが許容されるのに対して、コンテンツは数種類のみが許容されます。
 
そのルールは次のようになります。


If the content enhances the OS user experience, then the content is OK to be packaged in Fedora. This means, for example, that things like: fonts, themes, clipart, and wallpaper are OK.
コンテンツが OS のユーザエクスペリエンスを拡張するなら、そのコンテンツは Fedora へパッケージングして良いです。例えば、フォント、テーマ、クリップアートや壁紙のようなコンテンツになります。


Content still has to be reviewed for inclusion. It must have an open source compatible license, must not be legally questionable. In addition, there are several additional restrictions for content:
それでもコンテンツは含めて良いかどうかをレビューされる必要があります。オープンソース互換ライセンスである必要があり、法的な問題があってはいけません。さらに、コンテンツには追加の制約があります。
* Content must not be pornographic, or contain nudity, whether animated, simulated, or photographed. There are better places on the Internet to get porn.
* コンテンツはアニメ、擬似的、写真であるかによらずポルノ又はヌードであってはいけません。
* Content should not be offensive, discriminatory, or derogatory. If you're not sure if a piece of content is one of these things, it probably is.
* コンテンツは不快で、差別や名誉を毀損するようなものであってはいけません。コンテンツの一部がそれに該当するかどうかよく分からないなら、それはおそらく該当します。
* All content is subject to review by FESCo, who has the final say on whether or not it can be included.
* 全てのコンテンツは含めることが可能かどうかの最終決定権を持つ FESCo によってレビューされて従わなければなりません。


Some examples of content which is permissable:
許容されるコンテンツ例は次の通りです。


* Package documentation or help files
* パッケージのドキュメント、又はヘルプファイル
* Clipart for use in office suites
* Office 製品に使用されるクリップアート
* Background images (non-offensive, discriminatory, with permission to freely redistribute)
* 背景画像(不快な気分や差別にならない、フリーに再配布可能)
* Fonts (under an open source license, with no ownership/legal concerns)
* フォント(所有権や法的な懸念事項がないオープンソースライセンス)
* Game levels are not considered content, since games without levels would be non functional.
* ゲームレベルはコンテンツと見なされません
* Sound or graphics included with the source tarball that the program or theme uses (or the documentation uses) are acceptable.
* プログラム又はテーマ(又はドキュメント)が使用するソースの tar ボールに含まれるサウンド又はグラフィックは許容されます
* Game music or audio content is permissible, as long as the content is freely distributable without restriction, and the format is not patent encumbered.
* そのフォーマットに特許がなくコンテンツがフリーに制約なく配布できる限り、ゲーム音楽コンテンツは許容されます
* Example files included with the source tarball are not considered content.
* ソースの tar ボールに含まれるサンプルファイルコンテンツとは見なされません


Some examples of content which are not permissable:
許容されないコンテンツ例は次の通りです。


* Comic book art files
* マンガ本のファイル
* Religious texts
* 宗教に関するテキスト
* mp3 files (patent encumbered)
* mp3 ファイル(専売特許のある)


If you are unsure if something is considered approved content, ask on fedora-devel-list.
どんなコンテンツが許容されるかよく分からないなら、fedora-devel-list で尋ねてください。


{{Anchor|FileAndDirectoryOwnership}}
{{Anchor|FileAndDirectoryOwnership}}
== ファイルとディレクトリの所有者 ==
== ファイルとディレクトリの所有者 ==


Your package should own all of the files that are installed as part of the %install process.  Packages must not own files already owned by other packages. The rule of thumb here is that the first package to be installed  should own the files that other packages may rely upon. This means, for example, that no package in Fedora should ever share ownership with any of the files owned by the <code>filesystem</code> or <code>man</code> package. If you feel that you have a good reason to own a file or that another package owns, then please present that at package review time.
パッケージは %install セクションでインストールされる全てのファイルを所有すべきです。そして、パッケージは他のパッケージが既に所有しているファイルを所有してはいけません。基本原則として最初にインストールされるパッケージが、他のパッケージがそのファイルの存在に依存する可能性があるファイルを所有すべきです。例えば、これは <code>filesystem</code> 又は <code>man</code> パッケージによって所有されるファイルであっても所有権を共有するようなパッケージは Fedora にはないということです。もし他のパッケージが所有しているファイルを所有するための適切な理由があるなら、パッケージレビューのときに連絡してください。


Directory ownership is a little more complex than file ownership.  Although the rule of thumb is the same: own all the directories you create but none of the directories of packages you depend on, there are several instances where it's desirable for multiple packages to own a directory.
ディレクトリの所有者はファイルの所有者よりも少し複雑です。パッケージは自分が追加したファイルがある全てのディレクトリを所有しなければなりません。但し、次のディレクトリは除外されます。


In all cases we are guarding against unowned directories being present on a system.  Please see [[Packaging:UnownedDirectories]] for the details.
* <code>filesystem</code> や <code>man</code> 又はその他に明示的に作成された <code>-filesystem</code> が所有するディレクトリ


{{admon/important|Note on multiple ownership| Note that when co-owning directories, you <b>must</b> ensure that the ownership and permissions on the directory match in all packages that own it.}}
* パッケージの自然な依存関係のつながりで他のパッケージが所有するディレクトリ


{{admon/important|Note on directories| If a directory is explicitly required by packages in Fedora (such as <code>/usr/lib/mozilla/plugins</code>), only one package should own it, so that dependency solving is deterministic.}}
この文脈で言う、パッケージの "自然な依存関係のつながり" というのは、普通にそのパッケージが機能を提供するために必要なパッケージセットと定義されます。具体的に言うと、あなたのパッケージが追加するファイルのディレクトリを所有するという、ただそれだけのためにパッケージを要求する必要はありません。また、もしあなたのパッケージが別の理由でそのパッケージを既に要求しているなら、そのディレクトリを所有すべきではありません。


Here are examples that describe how to handle most cases of directory ownership.
全てのケースにおいて、システム上に存在するどのパッケージにも所有されていないディレクトリは保護しています。詳細は [[Packaging:UnownedDirectories]] を参照してください。


=== パッケージの全てに含まれる、又はコアな機能によって使用されるディレクトリ ===
{{admon/important|複数パッケージが所有することの注意| 複数パッケージが共通のディレクトリを所有する場合、全てパッケージでそのディレクトリの所有者とパーミッションが一致していることを保証<b>しなければならない</b>ことに注意してください。}}
 
ほとんどのディレクトリの所有に関連するケースにおいて、どのように取り扱うかを例で説明します。
 
=== パッケージ全体に含まれる、又はコア機能によって使用されるディレクトリ ===
 
例:


An example:
<pre>
<pre>
gnucash places many files under the /usr/share/gnucash directory
gnucash は /usr/share/gnucash directory 配下に多くのファイルを置きます
</pre>
</pre>


Solution: the <code>gnucash</code> package should own the <code>/usr/share/gnucash</code> directory
解決方法: <code>gnucash</code> パッケージは <code>/usr/share/gnucash</code> ディレクトリを所有すべきです


=== 巨大な環境インフラの一部になる多くのディレクトリに存在するファイルを置くパッケージ ===
=== 要求されたパッケージの機能を実装するパッケージにも所有されるディレクトリ ===
 
例:


An example:
<pre>
<pre>
kdeutils places files in (among other places)
pam は /etc/pam.d directory を所有します
/usr/share/applications/kde4
gdm は /etc/pam.d 配下にファイルを置きます
/usr/share/kde4/apps
/usr/share/kde4/services
</pre>
</pre>


Solution: the infrastructure directories above should be placed in a <code>kde-filesystem</code> package, and <code>kdeutils</code> should <code>Require:</code> the <code>kde-filesystem</code> package.
解決方法: <code>pam</code> パッケージは <code>/etc/pam.d</code> ディレクトリを所有すべきです。そして、<code>gdm</code> は <code>Require: pam</code> とします。
 
=== あなたのパッケージが機能を提供するために必要ではないパッケージがディレクトリを所有する ===
 
Some packages create and own directories with the intention of permitting other packages to store appropriate files, but those other packages do not need that original package to be present to function properly.


=== 要求されたパッケージの機能を実装するパッケージによっても所有されるディレクトリ ===
適切なファイルを格納するために他のパッケージを許容する目的でディレクトリを作成、所有しますが、そういった他のパッケージは正常に機能を提供するためにそのオリジナルのパッケージを必要としません。


An example:
例:


<pre>
<pre>
pam owns the /etc/pam.d directory
gtk-doc は /usr/share/gtk-doc/ を所有します
gdm places files into /etc/pam.d
evolution は /usr/share/gtk-doc/ にファイルを置きます
evolution は正常に機能を提供するために gtk-doc を必要としません
evolution の依存関係の繋がりには /usr/share/gtk-doc/ を所有するパッケージはありません
</pre>
</pre>


Solution: the <code>pam</code> package should own the <code>/etc/pam.d</code> directory, and <code>gdm</code> should <code>Require:</code> the <code>pam</code> package.
解決方法: <code>evolution</code> パッケージは <code>/usr/share/gtk-doc</code> ディレクトリを所有すべきです。gtk-doc をディレクトリの所有権のためだけに明示的に Require: へ追加する必要はありません。


=== 複数パッケージが共通ディレクトリにあるファイルを所有するが、それらのファイルは他のパッケージを要求する必要がない ===
{{admon/important|例外|稀に <code>mozilla-filesystem</code> のように、"見せかけのファイルシステム" が所有するようなディレクトリの方が望ましいこともあるでしょう。これらのパッケージは他のパッケージがそのディレクトリへファイルを格納する際に明示的に要求するように設計されます。このような状況では、見せかけのファイルシステムパッケージを明示的に Require: へ追加すべきであり、そういったディレクトリを複数のパッケージが所有すべきではありません。パッケージャは、見せかけのファイルシステムパッケージを作成するかを決めるときに影響のあるディレクトリやパッケージの数を考慮すべきです。そして、必要かどうかの最善の判断を自分で行います。}}


An example:
別の例:


<pre>
<pre>
bash-completion owns the /etc/bash_completion.d directory and uses the files placed there to configure itself.
bash-completion は /etc/bash_completion.d ディレクトリを所有して、そこに置かれたファイルを自身の設定のために使用します。
git places files into /etc/bash_completion.d
git は /etc/bash_completion.d にファイルを置きます
bzr places files into /etc/bash_completion.d
bzr は /etc/bash_completion.d にファイルを置きます
</pre>
</pre>


Solution: Both the git and bzr packages should own the /etc/bash_completion.d directory as bash-completion is optional functionality and the installation of git or bzr should not force the installation of bash-completion.
解決方法: git と bzr パッケージの両方とも bash-completion がオプション機能であるかのように /etc/bash_completion.d ディレクトリを所有すべきです。そして、git や bzr のインストールは bash-completion のインストールを強制しないようにします。
{{admon/important|Rule of Thumb|When determining whether this exception applies, packagers and reviewers should ask this question: Do the files in this common directory enhance or add functionality to another package, where that other package is not necessary to be present for the primary functionality of this package?}}


=== あるディレクトリを提供するために依存するパッケージは、後のバージョンになって違うディレクトリを所有するように変更されるかもしれません、そして、あなたのパッケージはその後のバージョンで何の変更もなく実行されます ===
{{admon/important|基本原則|この例外が適用されるかどうかを決定するとき、パッケージャとレビューアはこの質問をすべきです。この共通ディレクトリに存在するそのファイルは他のパッケージに対して機能を追加したり、拡張したりしますか？ここで他のパッケージはこのパッケージの主機能を提供するのに必要ではありません。}}


One common example of this is a Perl module.  Assume ''perl-A-B'' depends on ''perl-A'' and installs files into /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi/A/B.  The base Perl package guarantees that it will own /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi for as long as it remains compatible with version 5.8.8, but a future upgrade of the ''perl-A'' package may install into (and thus own) /usr/lib/perl5/vendor_perl/5.9.0/i386-linux-thread-multi/A.  So the ''perl-A-B'' package needs to own /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi/A as well as /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi/A/B in order to maintain proper ownership.
=== あるディレクトリの提供に依存するパッケージは、その後のバージョンで違うディレクトリを所有するように変更されるかもしれません、そして、あなたのパッケージはその後のバージョンで何の変更もなく実行されます ===


{{Anchor|DuplicateFiles}}
一般的な例の1つとして Perl モジュールがあります。
=== 重複したファイル ===
A Fedora package must not list a file more than once in the spec file's %files listings.  If you think your package is a valid exception to this, please bring it to the attention of the Packaging Committee so they can improve on this Guideline.


{{Anchor|FilePermissions}}
''perl-A-B'' が ''perl-A'' に依存して、/usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi/A/B にファイルをインストールすると仮定してください。ベースとなる Perl パッケージはバージョン 5.8.8 で互換性を維持する限り /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi を所有することを保証します。しかし、将来 ''perl-A'' パッケージのアップグレードパッケージが /usr/lib/perl5/vendor_perl/5.9.0/i386-linux-thread-multi/A (このディレクトリを所有する)にファイルをインストールするかもしれません。そのため、''perl-A-B'' パッケージは適切な所有者情報を維持するために /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi/A/B と同様に /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi/A を所有する必要があります。
=== ファイルパーミッション ===
Permissions on files must be set properly. Executables should be set with executable permissions, for example. Every <code>%files</code> section must include a <code>%defattr(...)</code> line. Here is a good default:
<pre>
%files
%defattr(-,root,root,-)
</pre>
Unless you have a very good reason to deviate from that, you should use <code>%defattr(-,root,root,-)</code> for all <code>%files</code> sections in your package.


{{Anchor|UsersAndGroups}}
{{Anchor|UsersAndGroups}}
Line 1,003: Line 1,067:
== 競合 ==
== 競合 ==


Whenever possible, Fedora packages should avoid conflicting with each other. Unfortunately, this is not always possible. For full details on Fedora's Conflicts policy, see: [[Packaging:Conflicts]] .
できるだけ Fedora パッケージはお互いに競合しないようにすべきです。しかし、不幸にも常にそうであるとは限りません。Fedora の競合ポリシーの詳細については [[Packaging:Conflicts|競合]] を参照してください。


Tools such as Alternatives and Environment Modules can also help prevent package conflicts.
また、代替ツールや環境モジュールのようなツールもパッケージが競合しないように使用することができます。


=== 代替のもの ===
=== 代替ツール ===


The "alternatives" tool provides a means for parallel installation of packages which provide the same functionality by maintaining sets of symlinks. For full details on how to properly use alternatives, see [[Packaging:Alternatives]].
代替ツールは、シンボリックリンクセットを維持することで同じ機能を提供するパッケージの並行インストールを行う方法を提供します。代替ツールの使用方法の詳細については[[Packaging:Alternatives|代替ツール]]を参照してください。


=== 環境モジュール ===
=== 環境モジュール ===


When there are multiple variants that each serve the needs of some user and thus must be available simultaneously by users, the alternatives system simply isn't enough since it is system-wide. In such situations, use of Environment Modules can avoid conflicts. For full details on how to properly use Environment Modules, see [[Packaging:Environment Modules]].
それぞれがユーザのニーズを提供していて、且つ同時に利用可能でなければならない複数の要因がある場合、システム全体に渡るので代替ツールは十分ではありません。そのような状況では、環境モジュールを使用すると競合を避けることができます。環境モジュールの使用方法の詳細については[[Packaging:Environment Modules|環境モジュール]]を参照してください。


== 拡張カーネルモジュールはありません ==
== 拡張カーネルモジュールはありません ==
{{:Packaging:KernelModules}}
{{:Packaging/KernelModules/ja}}


{{Anchor|NoFilesOrDirectoriesUnderSrv}}
{{Anchor|NoFilesOrDirectoriesUnderSrv}}
== /srv 配下のファイルやディレクトリはありません ==
== /srv 配下のファイルやディレクトリはありません ==


The [http://www.pathname.com/fhs/pub/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYSTEM FHS says] :
[http://www.pathname.com/fhs/pub/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYSTEM FHS によると]


<pre>
<pre>
"...no program should rely on a specific subdirectory structure of /srv existing
"/srv 配下の階層における特定サブディレクトリが存在していることや /srv 内に格納しなければならない
or data necessarily being stored in /srv. However /srv should always exist on FHS
データに依存するようなプログラムはありません。しかし、/srv は FHS 準拠のシステムとしては存在する
compliant systems and should be used as the default location for such data.
必要があるので、データのためにデフォルトの場所として使用されるべきです。


Distributions must take care not to remove locally placed files in these
Linux ディストリビューションは、管理者権限なしで /srv 配下に置かれたファイルを削除しないように
directories without administrator permission."
注意しなければなりません。"
</pre>
</pre>


/srv is a poorly implemented section of the FHS, and its intended use case is unclear. At this time, no Fedora package can have any directories or files under /srv.
/srv は FHS のセクションとしては曖昧な実装であり、その意図された使用方法はよく分かりません。現時点では、Fedora のパッケージは /srv 配下にファイルやディレクトリを置くことはできません。


It is important to note that a Fedora package, once installed, and run by a user, can use /srv as a default location for data. The package simply must not own any directories or files in /srv.
Fedora パッケージをインストールしてユーザが実行したら /srv はデータのためのデフォルトの場所として使用できるということに注意しなくてはいけません。但し、パッケージは /srv 配下にあるディレクトリやファイルを所有してはいけません。


{{Anchor|Bundling}}
{{Anchor|Bundling}}
== 複数プロジェクトをビルドすること ==
 
Fedora packages should make every effort to avoid having multiple, separate, upstream projects bundled together in a single package.
== 複数プロジェクトのビルド ==
 
Fedora パッケージは1つのパッケージ内に複数の、独立した、アップストリームのプロジェクトをまとめて含めないように最大限の努力をするべきです。


{{Anchor|AvoidFontBundling}}
{{Anchor|AvoidFontBundling}}
=== 他のパッケージにあるフォントを1つにまとめないこと ===
Fonts in general-purpose formats such as Type1, OpenType TT (TTF) or OpenType CFF (OTF) are subject to specific packaging guidelines ([[Packaging:FontsPolicy|1]]), and should never be packaged in a private application directory instead of the system-wide font repositories.
For more information, see: [[Packaging:FontsPolicy#Package_layout_for_fonts]].


== 全てのパッチはアップストリームのバグへのリンクやコメントを持つべきであること ==
=== 他のパッケージにあるフォントを1つにまとめない ===
 
Type1、OpenType TT (TTF) や OpenType CFF (OTF) のような汎用フォーマットのフォントは特殊なパッケージングガイドライン([[Packaging:FontsPolicy|1]])に従います。そういったフォントは、個別のアプリケーションディレクトリではなく、システム全体のフォントリポジトリにパッケージングされます。
詳細については[[Packaging:FontsPolicy#Package_layout_for_fonts]]を参照してください。


All patches in Fedora spec files '''SHOULD''' have a comment above them about their upstream status.  Any time you create a patch, it is best practice to file it in an upstream bug tracker, and include a link to that in the comment above the patch.  For example:
== 全てのパッチはアップストリームのバグへのリンクかコメントを持つようにする ==
 
Fedora の spec ファイルに含まれる全てのパッチは、そのパッチの上にアップストリームの状況に関するコメントを '''記載するべき''' です。パッチを作成するときは常に、作成したパッチをアップストリームのバグトラッカーへ登録するようにするのがベストプラクティスです。そして、そのパッチの上にコメントとして、バグトラッカーのバグ情報へのリンクを含めます。例えば、次の通りです。


<pre>
<pre>
Line 1,054: Line 1,123:
</pre>
</pre>


The above is perfectly acceptable; but if you prefer, a brief comment about what the patch does above can be helpful:
この例の記載内容で全く問題はありません。しかし、もっと良いのは、バグトラッカーのリンクの上にそのパッチがどういったものかの簡潔なコメントがあると分かり易いです。


<pre>
<pre>
Line 1,062: Line 1,131:
</pre>
</pre>


Sending patches upstream and adding this comment will help ensure that Fedora is acting as a good FLOSS citizen (see [[PackageMaintainers/WhyUpstream| Why Upstream?]] ).  It will help others (and even you) down the line in package maintenance by knowing what patches are likely to appear in a new upstream release.
アップストリームへパッチを送ることやこのコメントを追加することは、Fedora が良い FLOSS 市民([[PackageMaintainers/WhyUpstream|なぜアップストリーム？]]を参照)であることの証明になります。そうすることで、他の人(やあなたも)がアップストリームの新たなリリースで適用されそうなパッチがどういったものかを知ることによって、完全なパッケージメンテナンスを維持することに役立ちます。


=== アップストリームがバグトラッキングシステムを持っていない場合 ===
=== アップストリームがバグトラッキングシステムを持っていない場合 ===
You can indicate that you have sent the patch upstream and any known status:
 
アップストリームへパッチを送ったという事実とその状況を提示しましょう。


<pre>
<pre>
Line 1,078: Line 1,148:


=== Fedora に特化した(アップストリームで拒否された)パッチ ===
=== Fedora に特化した(アップストリームで拒否された)パッチ ===
It may be that some patches truly are Fedora-specific; in that case, say so:
 
パッチによっては Fedora に特化した修正もあるかもしれません。そのような場合は次のように記載します。


<pre>
<pre>
Line 1,086: Line 1,157:


{{Anchor|Epochs}}
{{Anchor|Epochs}}
== Epoch の使用 ==
== Epoch の使用 ==


Line 1,095: Line 1,167:


== シンボリックリンク ==
== シンボリックリンク ==
There are two ways of making a symlink, either as a relative link or an absolute link. In Fedora, neither method is required. Packagers should use their best judgement when deciding which method of symlink creation is appropriate.


=== 関連のあるシンボリックリンク ===
シンボリックリンクを作成するときに相対パスか絶対パスかのどちらかで作成することができます。Fedora では、どちらか一方の方法のみに限定していません。パッケージャはシンボリックリンクの作成について必要なときに最適な方法を選択すべきです。
A relative symlink is a symlink which points to a file or directory relative to the position of the symlink. For example, this command would create a relative symlink:
 
=== 相対パスのシンボリックリンク ===
 
相対パスのシンボリックリンクはファイルやディレクトリを相対パスで指すシンボリックリンクです。例えば、次のコマンドは相対パスのシンボリックを作成します。
<pre>
<pre>
ln -s ../..%{_bindir}/foo %{buildroot}/bin/foo
ln -s ../..%{_bindir}/foo %{buildroot}/bin/foo
</pre>
</pre>


Pros:
良い点:
* Relative symlinks will point to the same file inside or outside of a chroot.
* 相対パスのシンボリックリンクは chroot の内外で同じファイルを指します。


Cons:
悪い点:
* Much more complicated to create than absolute symlinks
* 絶対パスのシンボリックリンクの作成と比較するとずっと複雑です。
* Relative symlinks may break or behave unexpectedly when a part of a filesystem is mounted to a custom location.
* 相対パスのシンボリックリンクはファイルシステムの一部が特別な場所にマウントされていると壊れたり、予想もしない動作を引き起こす可能性があります
* Relative symlinks may break when bind mounting or symlinking directories.
* 相対パスのシンボリックリンクはバインドマウントやディレクトリを指すときに壊れる可能性があります
* Relative symlinks may make it more difficult to use rpm system macros.
* 相対パスのシンボリックリンクの作成に rpm のシステムマクロを使用するのはかなり難しいです。


=== 廃止されたシンボリックリンク ===
=== 絶対パスのシンボリックリンク ===
An absolute symlink is a symlink which points to an absolute file or directory path. For example, this command would create an absolute symlink:
 
絶対パスのシンボリックリンクはファイルやディレクトリを絶対パスで指すシンボリックリンクです。例えば、次のコマンドは絶対パスのシンボリックリンクを作成します。
<pre>
<pre>
ln -s %{_bindir}/foo %{buildroot}/bin/foo
ln -s %{_bindir}/foo %{buildroot}/bin/foo
</pre>
</pre>


Pros:
良い点:
* Much easier to create than relative symlinks.
* 相対パスのシンボリックリンクの作成と比較すると簡単です。
* Absolute symlinks work properly when bind mounting or symlinking directories.
* 絶対パスのシンボリックリンクはバインドマウントやディレクトリを指すときに正常に動作します。
* Absolute symlinks work well with rpm system macros.
* rpm のシステムマクロを使用して正常に動作します。


Cons:
悪い点:
* Absolute symlinks may break when used with chroots.
* 絶対パスのシンボリックリンクは chroot を使用すると壊れる可能性があります。


== man ページ ==
== man ページ ==
Line 1,216: Line 1,291:
=== Wordpress ===
=== Wordpress ===
Wordpress 拡張パッケージのためのガイドライン: [[Packaging:WordPress plugin packaging guidelines]]
Wordpress 拡張パッケージのためのガイドライン: [[Packaging:WordPress plugin packaging guidelines]]
[[Category:Packaging guidelines]]

Latest revision as of 21:04, 8 November 2018

パッケージングガイドライン

パッケージングを行う際、パッケージに関しての問題を指摘するのはレビューアの責任で、そのパッケージャの責任はレビューアから指摘された問題に対応することです。レビューアとパッケージャは問題の重要度(そのパッケージを公開しないようにするか、リポジトリに追加した後で対応できるかどうか)を判断するために一緒に作業します。パッケージングガイドラインはパッケージング全般に共通する問題やリポジトリに追加すべきかどうかの重要度の判断方法をまとめたものです。これらのガイドラインは無視して良いものではありませんが、とにかく何でも従えば良いと言うものでもありません。

パッケージを作成していて、そのパッケージがガイドラインの一部の内容に従う必要はないと思ったら、どうか Fedora パッケージ委員会へその問題を提示するようにしてください。

どのようなパッケージでもレビューガイドラインに沿って確認しなければならないことを必ず覚えておいてください。

Author: Tom 'spot' Callaway (他の多くのドキュメントに基づいています)
Revision: 1.00
Initial Draft: Wednesday Feb 23, 2005
Last Revised: Tuesday July 21, 2009

名前付け

パッケージの名前が適切かどうかを判断するために名前付けガイドラインに目を通すべきです。

バージョンとリリース

バージョンとリリースのフィールドへの適切な番号の設定方法は名前付けガイドライン:パッケージバージョンで確認することができます。

法律

Fedora でパッケージングを行う際に考慮する必要がある様々な法的な内容があります。

ライセンス

パッケージのライセンスが適切かどうかを判断するためにライセンスとライセンスガイドラインを再検討すべきです。

外部のコードなしでは使えないパッケージ

ランタイムオペレーティングシステム環境において、ソフトウェアの中には外部のコードがない状態では全く使えないものもあります。そういった依存する外部のコードが、フリーではなく、法的にも認められてないか、バイナリのみ(例外的に認められたファームウェア)の場合、その依存するソフトウェアは Fedora に含めることが認められていません。もし、そのコードの依存関係が Fedora 向けに認められたなら、準必須ソフトウェアとして Fedora に含めてパッケージングされるべきです。使える状態にするためにインターネットから集めてきたコードをダウンロードするようなソフトウェアは Fedora に含めることが認められていません(適切な依存関係として Fedora にパッケージングすることが認められているコードをダウンロードするかどうかに関係なく認められていません)。

また、これはサードパーティのソースからのパッケージ、又はコードがない状態で使えないようなパッケージは Fedora に含めることが認められていないということにもなります。

ビルド済みのバイナリやライブラリは含めない

Fedora のパッケージとして提供する全てのプログラムのバイナリやライブラリは、ソースパッケージに含められたソースコードからビルドされなければなりません。これは次のような理由から必要条件になります。

  • セキュリティ: ソースコードからビルドされていない準パッケージングされたプログラムのバイナリやライブラリは、悪意や危険、単に壊れているといった部分を含む可能性があります。また、パッチの作成もできません。
  • コンパイラフラグ: ソースコードからビルドされていない準パッケージングされたプログラムのバイナリやライブラリは、おそらくはセキュリティや最適化のための標準的な Fedora のコンパイラフラグでコンパイルされていません。

(.mo, .pdf, .png, .ps ファイルのような)コンテンツバイナリはソースコードからリビルドする必要はありません。

もしプログラムのバイナリやライブラリについて何か疑問に思うことがあれば、ここに分かり易い判断基準があります。

  • それは実行可能なものですか？もしそうなら、おそらくはプログラムのバイナリです。
  • それは .so, so.#, .so.#.#.# といった拡張子のファイルを含んでいますか？もしそうなら、それはおそらくプログラムのライブラリです。
  • 疑問に思ったら、レビューアに尋ねてください。レビューアが分からない場合、そのレビューアが Fedora パッケージング委員会へ尋ねるでしょう。

また、ビルドするためにオープンソースではないコンポーネントを要求するパッケージも認められていません。(例 プロプライエタリなコンパイラが必要とか)

あるパッケージ内にビルド済みのバイナリを見つけたら、次のことを守らなければなりません。

  • パッケージのビルドが行われる前に実行される %prep セクションで全てのビルド済みのプログラムのバイナリやライブラリを削除してください。例としては *.class, *.dll, *.DS_Store, *.exe, *.jar, *.o, *.pyc, *.pyo, *.egg, *.so などのファイルになりますが、これらのファイルのみに限定されるわけではありません。
  • 次のリリース時にバイナリを削除するようにアップストリームにお願いしてください。

例外事項

  • 以前のツールチェーンか、開発環境(オープンソース)を使用しないとビルドできないソフトウェア(通常はコンパイラ、又はクロスコンパイラ環境に関連します)があります。この判断が必要な状況に遭遇したら、承認をもらうために Fedora パッケージング委員会へ連絡してください。
  • バイナリのファームウェアのために作成された拡張機能は、それが必要条件であり続ける限り、ライセンスのバイナリファームウェアに記載されています。
  • 前もってパッケージングされたプログラムのバイナリやライブラリによっては再配布が許可されていない、又は特許のような法的な影響を受ける条項が含まれているかもしれません。そのような状況では、シンプルにそういったファイルを %prep セクションで削除すれば良いというわけではありません。メンテナはそういったファイルを含めないように変更したソースを作成する必要があります。パッケージング:ソース URL のアップストリームが禁止されているコードを使用しているときを参照してください。

Spec ファイルの読み易さ

全ての Fedora パッケージの spec ファイルは読み易い内容でなければなりません。レビューアが spec ファイルを読んで理解できない場合、レビュー作業ができないことになります。Fedora の spec ファイルはコードの難読化コンテストに参加するためのものではありません。

スクラッチからのパッケージ作成

スクラッチからパッケージを作成するとき、Fedora の spec ファイルテンプレート(Rpmdevtools を参照)をベースとして使用すべきです。spec ファイルのフォーマットや構成方法に関しては優先して、できるだけこのテンプレートを確認するようにしてください。その理由はこの spec ファイルが spec ファイルを書く唯一の正しい方法だと信じているからではありません。しかし、テンプレートを使用する方が誤りを発見し易かったり、やりたいことを素早く理解し易かったりするので品質を高めることになるからです。

既存のパッケージからの修正

既存の Fedora パッケージ以外のパッケージをベースにする場合、その正当性の検証とそのパッケージをインストールして使用することで何か問題が発生しないかを厳密に調査するようにしてください。何か変なことが起こらないかを調査していない状態でパッケージを追加するように提案しないでください。一見、害が無さそうに見えるコマンドも調査対象になります。

特に次のことをすべきです。

  • 全てのソースとパッチを検証する
  • spec ファイルに記載されているライセンスと実際のソフトウェアのライセンスがあっているかを検証する(タグを参照)
  • 要約とパッケージ説明内容の誤植や奇妙な箇所を修正する(要約とパッケージ説明内容を参照)
  • 正しいビルドルートが使用されているかを確認する
  • マクロの使用方法で一貫性があるかを確認する(マクロを参照)

オリジナルの作成者の履歴である古い changelog のエントリを保持してください。かなり古いバージョンか、何年分ものエントリは削除されるかもしれません。もし根本的な変更を行った場合、いずれにしても spec ファイルの大部分を書き直すことになります。 自由にスクラッチから changelog を書き始めるようにしてください。言い換えれば、自分で最良の判断をするようにしてください。

アーキテクチャのサポート

全ての Fedora パッケージは少なくとも1つの主要なアーキテクチャをサポートして、ソースのコンパイルとバイナリ RPMS をビルドできなければなりません。Fedora パッケージャは全ての主要なアーキテクチャをサポートするように努めるべきです。

コンテンツ、コンパイル/ビルドを行う必要のないコードやアーキテクチャから独立したコード(noarch)は目立った例外になります。

アーキテクチャの違いによるビルドの失敗

あるアーキテクチャ上でビルドできて動作する Fedora パッケージが他のアーキテクチャでコンパイルに失敗する場合、失敗するアーキテクチャは spec ファイルに ExcludeArch を設定すべきです。ExcludeArch に設定された各々のアーキテクチャは、そのアーキテクチャでコンパイル/ビルド/実行に失敗する理由を説明して bugzilla に登録する必要があります。登録したバグ ID は対応する ExcludeArch 行の隣にコメントとして記載すべきです。新しいパッケージはレビュープロセスの間は bugzilla エントリを持っていないので、そのパッケージが承認されるまでコメントに失敗する理由を記載するようにしてください。そして、承認された後で bugzilla に登録して、記載した長い説明をバグ ID に置き換えてください。そういったバグはシンプルに問題を追跡するために、以下のバグの blocking(もしくはそれ以上) としてマークされます。

ファイルシステムの置き場所

Fedora はファイルシステムの階層に関してファイルシステム階層標準(FHS)に準拠しています。FHS はシステム上のファイルの置き場所を定義します。Fedora パッケージは FHS に準拠しなければなりません。パッケージがレビューされるときに FHS から逸脱していたら正しい置き場所に修正すべきです。

このガイドラインに対して(GNU コーディング標準で特別扱いされている) libexecdir とクロスコンパイラのための /usr/target に目立った例外があります。

libexecdir

ファイルシステム階層標準(FHS)には libexecdir に関しての定義はありませんが、Fedora パッケージはその場所にファイルを置くことができます。libexecdir(Fedora システム上では /usr/libexec)はユーザが使用するというよりも主に他のプログラムによって実行されるように設計された実行プログラムのためのディレクトリとして使用すべきです。 Fedora の rpm は libexecdir のためのマクロ、%{_libexecdir} があります。パッケージャは %{_libexecdir}/%{name} のような、パッケージに特化した %{_libexecdir} のサブディレクトリに libexecdir ファイルを保存することが強く推奨されます。

rpmlint の使用

共通エラーの調査のために rpmlint を実行して、(rpmlint が間違っていない限り発生するエラーも含めて) RPM のエラーを修正するようにしてください。もし rpmlint の出力がよく分からないなら、大半のエラーとワーニングのもっと詳細な情報を取得できる -i オプションを付けるようにします。rpmlint パッケージは Fedora のリポジトリで利用可能です。

rpmlint エラー

rpmlint は完全に有効なパッケージだったとしても実行時に多くのゴミ出力を生成することがあります。このセクションでは、必要に応じて修正できるように、たくさん出力されるメッセージを解釈するのに役立つ情報を記載します。

  • E: foo-package no-packager-tag: このエラーは spec ファイルで Packager: が定義されていないときに発生します。Fedora では Packager タグを使用しないので、このエラーは無視することができます。
  • E: foo-package no-signature: このエラーはパッケージが署名されていないときに発生します。Fedora は CVS に SRPMS を保存しないので(SRPMS の中に含まれるファイルのみ保存する)、パッケージに署名する必要はありません。そのため、このエラーは無視することができます。
  • W: foo-package summary-ended-with-dot Summary of my package.: このエラーは spec ファイルの Summary: の内容がピリオドで終わっているときに発生します。ただ、行の最後からピリオドを削除してください。
  • E: foo-package wrong-script-end-of-line-encoding /path/to/somefile: このエラーはファイル中で DOS の改行が使用されているときに発生します。%prep セクションで sed を使用して %{__sed} -i 's/\r//' src/somefile とするか、dos2unix で修正してください。
  • E: foo-package invalid-lc-messages-dir /usr/share/locale/xx_XX/LC_MESSAGES/foo.mo: このエラーはよくある誤り検出で、通常は無視されます。

Changelogs

何か変更するときはいつも、パッケージの E-V-R(エポック-バージョン-リリース)を増加させて、changelog エントリに追加してください。changelog はパッケージの履歴を管理するのみでなく、さらにユーザ、仲間のパッケージャ、QA 担当者にあなたが行った変更を見つけ易くなるといった点でも重要です。

個々の変更が Bugzilla のバグに関連する場合、簡易リファレンスのために changelog のエントリにバグ ID を含めてください。 

* Wed Jun 14 2003 Joe Packager <joe at gmail.com> - 1.0-2
- Added README file (#42).

次のフォーマットからどれか1つを使用しなければなりません。 

* Fri Jun 23 2006 Jesse Keating <jkeating@redhat.com> - 0.6-4
- And fix the link syntax.

* Fri Jun 23 2006 Jesse Keating <jkeating@redhat.com> 0.6-4
- And fix the link syntax.

* Fri Jun 23 2006 Jesse Keating <jkeating@redhat.com>
- 0.6-4
- And fix the link syntax.

changelog のエントリは、新たなバージョン番号、追加されたパッチ、その他の spec ファイルの修正、バグや、もしあれば CVE のエントリを含めたリリース間でそのパッケージに対して行われた変更内容の簡潔な要約を記載すべきです。絶対に変更された全ソースのコピーを CHANGELOG エントリに含めてはいけません。その目的は、多くの技術的な詳細とその変更内容でうんざりさせることなくアップデートされたパッケージで何が変更されたかについて、ユーザへヒントを与えることです。アップストリームの changelog へのリンクは追加情報を望むユーザのために含めることができます。

タグ

  • Packager タグは spec ファイルで使用すべきではありません。パッケージャの正体は changelog のエントリから明らかになります。Packager タグを使用しないことによって、ヘッダにあなたの名前があるのに、誰かがリビルドした良くないバイナリを見なくてすみます。また、www.rpm.org にある Packager タグの Maximum RPM の定義を参照してください。あなた自身がビルドした RPMS のパッケージャについての情報を含める必要があるなら、代わりに ~/.rpmmacros に %packager を使用するようにしてください。
  • Vendor タグは使用すべきではありません。それはビルドシステムが自動的に設定するようにします。
  • Copyright タグは廃止予定です。ライセンスガイドラインの詳細を確認して、代わりに License タグを使用してください。そのソフトウェアを再配布するライセンスが何になるかに疑問があるなら、アップストリームの作者に連絡してください。
  • Summary タグで記載した内容はビリオドで終わるべきではありません。文法的な観点からこれが気になるなら、一旦座って、深呼吸して、そして克服してください。
  • 通常は、PreReq タグはそのままの Requires タグに置き換えるべきです。詳細については、Maximum RPM snapshot の素晴らしく木目の細かい依存関係の章を参照してください。
  • Source タグはアップストリームのソースを見つけるための場所を記載します。大抵の場合、アップストリームの tar ボールへの完全な URL にすべきです。特別なケースでは、Packaging:SourceURL のガイドラインを参照してください。

BuildRoot タグ

Fedora(現在は F-10) は spec ファイルに BuildRoot タグを設定することを必要としません。そして、もし BuildRoot タグが定義されても無視されます。既に提供済みの buildroot は %install セクションにあるコマンドが呼び出される前に自動的に削除されます。

EPEL での違い
EPEL5 やそれ以下の rpm は BuildRoot タグを必要とします。そして手動で %install を削除しなければなりません。EPEL ガイドライン を参照してください

%clean

%clean セクションは F-13 やそれ以上から不要になります。F-12 やそれ以下(又は EPEL)では rm -rf %{buildroot} (又は $RPM_BUILD_ROOT) を含む %clean セクションを設定しなければなりません。

Requires

RPM は、例えば Perl モジュールなど、自動的にライブラリの依存関係を調べるというとても素晴らしい機能を持っています。要するに車輪の再発明をしなくて済みますが、rpm は依存関係のみを教えてくれます。libX11 パッケージのライブラリに依存している状態で rpm が既にその依存関係を取得している場合、通常は明示的に Requires: libX11 と定義する必要はありません。

BuildRequires は違います。自動的に依存関係を見つける処理はありません。それはつまり、ビルドが成功するために必要なパッケージの機能を明示的に定義しなければなりません。典型的な例として、BuildRequires に -devel パッケージが定義されます。 BuildRequires セクション を参照してください。

時々、ビルドするために gtk+-devel 1.2 かそれ以上のバージョンを要求をするパッケージを見かけます(そして、実行するためには gtk+ 1.2 かそれ以上が必要ですが、それは自動的に扱われます)。ここで考慮しておくことが2つあります。

1つ目は、要求する最も低いバージョンのパッケージがかなり古いもので、対象とするディストリビューションのリリースでインストールされているパッケージよりも古いバージョンなら、依存関係にそのバージョンを含める必要は全くありません。そのような例では、利用できるソフトウェアは新しいバージョンで十分です。gtk+-devel 1.2 以上の依存関係におけるバージョンは、(少なくとも)リリース 6.2 以降の全ての Red Hat のディストリビューションには不要です。大まかなルールとして、そのバージョンを要求しないなら、冗談半分にそのバージョンを追加しないでください。

2つ目は、エポック-バージョン-リリースの比較を堅牢にするためにバージョン指定された依存関係を追加するときに Epoch も定義しなければなりません。パッケージ foo の Epoch をチェックするための簡単な方法は次のように実行します。

rpm --query --qf "%{EPOCH}\n" packagename

典型的な例として、-devel パッケージのために他のパッケージを要求します。通常は rpm によって自動的に取得されません。foo-devel パッケージが foo-config スクリプトを持っているなら、どのパッケージを foo が要求しているかの強力な手掛かりとして foo-config --libs や foo-config --cflags を実行するようにしてください。 

$ gtk-config --cflags
-I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 -I/usr/lib/glib/include -I/usr/X11R6/include
$ gtk-config --libs
-L/usr/lib -L/usr/X11R6/lib -lgtk -lgdk -rdynamic -lgmodule -lglib -ldl -lXi -lXext -lX11 -lm

これは gtk+-devel が次のパッケージを要求していることになります。

Requires: glib-devel libXi-devel libXext-devel libX11-devel

PreReq

パッケージには PreReq を使用しないでください。昔々、RPM がインストールトランザクションの中でインストールの順番を決定するとき、依存解決のループの中で PreReq は標準の Require よりも "優先" するために使用していました。しかし、現在はこの用途には使用しません。

ファイルの依存関係

rpm にはパッケージの代わりにファイルの依存関係を持つ機能もあります。できるだけ /etc, /bin, /sbin, /usr/bin 又は /usr/sbin 以外でファイルの依存関係を使用しないようにしてください。そのようなディレクトリ以外のファイルの依存関係を使用することは依存関係を探す巨大な xml ファイルをダウンロードして解析するために yum (や repmod 形式を使用するその他の依存関係解決ツール)を必要とします。エンドユーザに待ち時間を取らせないために、ファイルではなくパッケージの依存関係を持たせることで依存関係解決ツールはこの処理を行いません。ファイルの依存関係は、こういった懸念事項よりも優先する他の技術的な検討事項があるときもあります。特別な例の1つとして %{_libdir}/mozilla/plugins にインストールされるパッケージです。この場合、ただこのディレクトリを所有するために特定ブラウザをパッケージの依存関係に持つと、多くの不要なパッケージを一緒にインストールされてしまいます。そういった依存関係を解決するためにディレクトリを要求する方が良い選択でしょう。

明示的な Requires

明示的な Requires とは spec ファイルでパッケージャが手動で追加した Requires です。パッケージには絶対的に必要な場合を除いてライブラリの明示的な Requires を定義してはいけません。明示的なライブラリの Requires が必要なときは、そのことを説明するコメントを spec ファイルに残すべきです。

一般的にはライブラリの SONAME の依存関係を自動的に追加する rpmbuild を信頼します。最近のパッケージ管理ツールは必要なパッケージを探してきて依存関係を解決する機能があります。特定のパッケージの明示的な依存関係は手動で RPM パッケージをインストールしようとしている経験の浅いユーザにとっては助けになるかもしれません。しかし、ライブラリ/ファイルをあるパッケージから別のものに移行した場合、パッケージ名が変更された場合、複数の代替パッケージのうち1つだけあれば十分な場合、バージョン指定された明示的な依存関係が古くなってしまった場合など、このような依存関係は混乱を招くことがこれまでの歴史から分かっています。さらに、あるケースでは、古い明示的な依存関係が不要なアップデート/リビルドを要求します。例えば、Fedora パッケージは2回のフルリリースサイクル向けに、過去の Provides を維持するためにのみ Requires します。

バージョン指定された明示的な依存関係のための模範的な定義は次の通りです。 

  # libfubar.so.1 の自動検出される依存関係は十分ではありません
  # 最低でも2つのセグメンテーションフォールトを修正したリリースを厳密に必要とします
  Requires: libfubar >= 0:1.2.3-7

パッケージャは明示的な依存関係が不正確で余分なものにならないように、必要に応じて見直すべきです。上述した例において、現時点の Fedora リリースが libfubar < 1.2.3-7 を提供していないなら、この明示的なバージョン指定された依存関係を今後も残しておく必要はありません。

自動生成された Requires/Provides を取り除く

RPM は Requires/Provides をビルド時に自動生成しようとしますが、状況によっては、自動生成された Requires/Provides は正しくないものか、望まないものです。自動生成された Requires/Provides を取り除く方法の詳細については Packaging:AutoProvidesAndRequiresFiltering を参照してください。

BuildRequires

パッケージ開発やテストの中で、ビルドに必要な依存関係が欠落していないかを検証してください。適切なビルドのための依存関係を定義することは自動ビルドシステムと同様に、全ての開発者とテスターの作業を効率化します。というのは、手動で欠落したビルドの依存関係を探す必要がないからです。また、それは何らかの要因によるビルドエラーではなく、極めて重要な機能を欠落させた状態でビルドしないようにするための安全な機能です。例えば、グラフのアプリケーションは、そのパッケージの configure スクリプトによって libpng がインストールされていないことを検出すると PNG サポートを排除するかもしれません。

BuildRequires をパッケージへ追加する前に、 Requires を適切に定義してください。

欠落した BuildRequires を検出する方法として2つの方法が提案されています。rpmdev-rmdevelrpms と mock です。rpmdev-rmdevelrpms はシステムから全ての開発関連パッケージを削除するように設計されています。もしビルドに失敗するか、ビルドのための依存関係が欠落して特定の機能がなくなってしまったら、欠落した依存関係を探して追加されます。詳細は rpmdev-rmdevelrpms セクションを参照してください。
mock はビルドの依存関係を確認する優れたもう1つの方法です。全ての開発関連パッケージ削除するよりも、chroot を行ってパッケージをビルドしようとします。その方法だと、通常の、毎日使用する環境を変更する必要はありません。そして、パッケージが正常にビルドされることを確認します。しかし、mock は要求された全てのパッケージをダウンロードするためにインターネットとの接続が必要です。 MockTricks に詳細があります。他に mock に似たツールで、 mach も Fedora のリポジトリで利用することができます。

rpmdev-rmdevelrpms

rpmdevtools ツールキットに含まれている rpmdev-rmdevelrpms スクリプトは、欠落した BuildRequires を探すために Ville Skyttä によって開発されました。シンプルにそのスクリプトを実行して、この例のような全ての *-devel パッケージとビルドツールを削除してください。 

[root@build-fc1 /] # rpmdev-rmdevelrpms
Found 52 devel packages:
guile-devel-1.6.4-8.2
bison-1.875-5
m4-1.4.1-14
flex-2.5.4a-30
openssl-devel-0.9.7a-23
automake-1.7.8-1
fontconfig-devel-2.2.1-6.1
XFree86-devel-4.3.0-42
tcl-devel-8.3.5-93
SDL_image-devel-1.2.3-3
SDL_ttf-devel-2.0.6-0.fdr.3.1
pth-devel-2.0.0-0.fdr.1.1
libIDL-devel-0.8.2-1
atk-devel-1.4.0-1
gtk2-devel-2.2.4-5.1
libmng-devel-1.0.4-4
glib-devel-1.2.10-11
gtk+-devel-1.2.10-28.1
audiofile-devel-0.2.3-7
compface-1.4-0.fdr.3.1
esound-devel-0.2.31-1
libungif-devel-4.1.0-16
gnome-libs-devel-1.4.1.2.90-35
openldap-devel-2.1.22-8
aspell-devel-0.50.3-16
gpgme03-devel-0.3.16-0.fdr.2.1
freeglut-devel-1.3-1.20020125.3
e2fsprogs-devel-1.34-1
db4-devel-4.1.25-14
krb5-devel-1.3.1-6
autoconf-2.57-3
libtool-1.5-8
gdbm-devel-1.8.0-21
freetype-devel-2.1.4-5
pkgconfig-0.14.0-6
ncurses-devel-5.3-9
tk-devel-8.3.5-93
SDL-devel-1.2.5-9
SDL_mixer-devel-1.2.4-9
zlib-devel-1.2.0.7-2
libgpg-error-devel-0.6-0.fr.3.1
glib2-devel-2.2.3-1.1
pango-devel-1.2.5-1.1
libjpeg-devel-6b-29
libpng-devel-1.2.2-17
ORBit-devel-0.5.17-10.3
clamav-devel-0.65-0.fdr.4.1
cyrus-sasl-devel-2.1.15-6
libtiff-devel-3.5.7-14
imlib-devel-1.9.13-14
gdk-pixbuf-devel-0.22.0-3.0
pilot-link-devel-0.11.8-1
Remove them? [y/N]  y[
]Removing.................................................................................................
................................................................Done.

その後、あなたの RPM パッケージをビルドしようとしてください。既に BuildRequires に定義しているパッケージは yum で再インストールしてください。もしこの時点でビルドに失敗したら、ビルド処理を調査する必要があります。そして、エラーログから欠落した BuildRequires を究明します。

パッケージに望まれるツールか、オプションのライブラリが欠落していないか、ビルド処理の configure の部分を特に注意深く確認してください。

デフォルトでは、rpmdev-rmdevelrpms スクリプトは、システムが正常に動作するために必要なパッケージを削除しようとするかもしれません。通常は、不十分な依存関係のために失敗するでしょう(これが、つまり yum remove の代わりに rpm -e を使用している理由です)。

この例としては gettext や libgcj パッケージがあります。gettext は通常は開発のみに使用されるパッケージですが、例えば redhat-lsb は gettext に依存します。また、RH9 の Konqueror は SSL のために openssl-devel を必要とします。rpmdev-rmdevelrpms が無視するパッケージを幾つかマークしたいなら、/etc/rpmdevtools/rmdevelrpms.conf か、ホームディレクトリの .rmdevelrpmsrc にその内容を設定してください。そして、ビルド時はこの方法で設定した対象パッケージに対して十分に注意するようにしてください。

例外事項

次のパッケージやその BuildRequires としての依存関係は、一般的によく使用されるので spec ファイルに定義する必要はありません。これらのパッケージは最小ビルド環境として認識されています。 

bash
bzip2
coreutils
cpio
diffutils
fedora-release
findutils
gawk
gcc
gcc-c++
grep
gzip
info
make
patch
redhat-rpm-config
rpm-build
sed
shadow-utils
tar
unzip
util-linux-ng
which

要約とパッケージ説明

要約は短くパッケージの説明内容を簡潔にしたものにすべきです。パッケージ説明は要約から発展させます。パッケージ説明にインストールガイドを含めないでください。それはマニュアルではありません。パッケージが手動設定か、ユーザに対する重要なインストールガイドを必要とするなら、パッケージのドキュメントを参照させるようにしてください。必要だと思ったら README.Fedora か、似たようなものを追加してください。また、パッケージ説明の1行は80文字以上にならないように注意してください。

個人的な優先度は置いておいて、要約やパッケージ説明にはアメリカ英語のつづりを使用してください。パッケージには、可能なら非英語圏のために翻訳された要約やパッケージ説明を追加で含めることもできます。

要約やパッケージ説明内容の商標

パッケージャは要約やパッケージ説明に商標を使用する方法に注意すべきです。次にルールがあります。

  • 決して "(TM)"、"(R)" (又はユニコードの ™/®) を使用しないでください。これらのマークを適切に使用するには信じられないぐらい複雑です。そのため、これらのマークを全く使用しないのが我々にとっては安全です。
  • 曖昧ではない方法で商標を使用してください。"似ている" とか "ような" というフレーズは避けてください。例があります。
  • 悪い例: Adobe Photoshop に似たものです
  • 良い例: Adobe Photoshop の PSD ファイルをサポートします ...
  • 悪い例: Microsoft Office の Linux バージョンです
  • 良い例: Microsoft Office の DOC ファイルをサポートするワードプロセッサです

あなたがよく分からないなら、誰かが混乱する可能性はないかと自問してください。そして、このパッケージは商標が必要かを考えてください。疑問に思ったら、商標を外すようにしてください。

文字エンコーディング

ASCII 文字の範囲外で文字を使用する必要がない限り、spec ファイルのエンコーディングについて考慮する必要はないでしょう。ASCII 文字以外を使用する必要があるなら、UTF-8 で spec ファイルを記述するようにしてください。ASCII 文字が何なのか分からないなら、このグラフを参照してください。

ASCII 文字ではないファイル名

同様に、ASCII 文字以外の文字を含むファイル名は UTF-8 でエンコードされなければなりません。ファイル名が何のエンコーディングかを設定する方法がないので、全てのファイル名に同じエンコーディングを使用することがユーザがファイル名を読めることを保証するために最も良い方法です。もしアップストリームが UTF-8 でエンコードされていないファイル名でリリースしていたら、%install セクションで(convmv パッケージにある)convmv のようなユーティリティを使用してファイル名を変換することができます。

ドキュメント

配布されているソースに含まれる、いかなる関連ドキュメントもパッケージ内に含まれるべきです。ビルド方法については無関係なドキュメントもあります。よくある INSTALL ファイルは一般的なビルド方法について記載していたり、例えば、README.MSDOS のように Linux 以外のシステムのドキュメントがあったりします。どのサブパッケージにドキュメントを含めるかにも注意を払ってください。例えば、API の例に関するドキュメントは -devel パッケージに含めて、メインパッケージには含めません。さらに大量にドキュメントがあるなら、サブパッケージに分割することを検討してください。この例では、サブパッケージの名前として *-doc が推奨されます。そして Group タグの設定は Documentation になります。

また、あるパッケージが %doc にドキュメントを含んでいるなら、アプリケーションの実行に影響を与えてはいけません。要約すると、ドキュメントが %doc にあるなら、そのプログラムはそこにドキュメントがなかったとしても正常に実行されなければなりません。

コンパイラフラグ

パッケージをビルドするために使用するコンパイラはシステム内で rpm 設定としてセットされた適切なコンパイラフラグを受け取るべきです。2006年8月以降は、C/C++ や Fortran コンパイラのために $RPM_OPT_FLAGS/%{optflags} が実際に使用されます。その変数の中身がパッケージのビルドにおいてコンパイラによって実際に使用される基本フラグになります。このフラグをフィルタリングしたり、追加や上書きしたりすることは、理由があるときには許可されています。そのように変更する論理的根拠は、特に上書きやフィルターするときに spec ファイル内に記載してレビューされるべきです。

Debuginfo パッケージ

パッケージングするときはデバッグに役立つ -debuginfo パッケージも作成すべきです。又は -debuginfo パッケージを生成できない場合は明示的に無効にすべきです。とは言え、いずれにしても rpmbuild がそうします。-debuginfo パッケージが明示的に無効にするなら、spec ファイル内にその理由を説明したコメントを記載します。Debuginfo パッケージの詳細については Packaging:Debuginfo を参照してください。

Devel パッケージ

あるソフトウェアで開発に必要なファイルを含めるようにパッケージングする場合、そのようなファイルは -devel サブパッケージに含めるようにすべきです。以下に -devel に含めるべきファイル種別の例を示します。

  • ヘッダファイル(.h ファイル)
  • バージョン指定のない共有ライブラリ(libfoo.so)。バージョン指定のある共有ライブラリ(libfoo.so.3, libfoo.so.3.0.0)は -devel に含めるべきではありません。

分かり易い基本原則として、あるファイルが開発のために使用されてベースパッケージで実行するのに必要ないなら、そのファイルを -devel に含めるべきです。

Pkgconfig ファイル

pkgconfig(.pc) ファイルをどのパッケージに含めるかは、その使用方法に依存します。pkgconfig ファイルは、ほとんど開発の目的のために使用されるので、-devel パッケージに含められます。分かり易い例外としては、メインパッケージそのものがユーザ向けのランタイムをインストールしない開発向けのツールがあります。例えば、gcc や gdb になります。

EPEL との違い
Fedora の rpm は自動的に pkgconfig と pkgconfig ファイルに関連する依存関係を検出します。EPEL5 又はそれ以下のバージョンの rpm はこの機能がないので EPEL ガイドラインに従うべきです。

ベースパッケージの要求

-devel パッケージは Requires: %{name} = %{version}-%{release} のようにフルバージョンの依存関係を使用してベースパッケージを要求しなければなりません。普通は、-devel 以外のサブパッケージもフルバージョンの依存関係を使用してベースパッケージを要求すべきです。

共有ライブラリ

できるだけ(そして適切なら)、ライブラリを含む Fedora パッケージは共有ライブラリとしてパッケージングすべきです。さらに、動的リンカの全てのデフォルトパスに存在する共有ライブラリファイル(単なるシンボリックリンクではない)を含むバイナリ RPM パッケージは %post や %postun スクリプトで /sbin/ldconfig コマンドを実行しなければなりません。パッケージがライブラリを含む複数のサブパッケージで構成される場合、各々のサブパッケージもまた %post や %postun スクリプトを /sbin/ldconfig コマンドを実行すべきです。正しい構文の例は次の通りです。 

%post -p /sbin/ldconfig

%postun -p /sbin/ldconfig

この特殊な構文は /sbin/ldconfig が %post や %postun で実行される場合にのみ有効であることを覚えておいてください。%post や %postun のスクリプトレットの中で他のコマンドを実行したい場合、次のように、そのスクリプトレットの最初に /sbin/ldconfig を実行するようにします。 

%post
/sbin/ldconfig
/usr/bin/foo --add

%postun
/sbin/ldconfig
/usr/bin/foo --remove

静的ライブラリのパッケージング

ライブラリを含むパッケージは、(例えば、--disable-staticを設定して)できるだけ静的ライブラリを除外すべきです。静的ライブラリは例外的な状況や理由がある場合にのみ含めるべきです。ライブラリをリンクするアプリケーションは、できるだけ静的ライブラリではなく共有ライブラリをリンクするようにすべきです。

libtool のアーカイブ、つまり foo.la のようなファイルは含めるべきではありません。libtool を使用するパッケージは --disable-static を設定してもデフォルトで foo.la のようなファイルをインストールします。そのため、パッケージングする前にそのようなファイルを削除する必要があるかもしれません。libtool の古いバージョンのバグ、又は libtool を使用するプログラムのバグのために、そのプログラムを変更せずに *.la ファイルを削除できない場合があります。ほとんどのケースでは、この問題を修正するためにアップストリームで作業することが最も簡単です。安定版(開発版ではない)リリースのライブラリをアップグレードする際にパッケージが既に *.la ファイルを含んでいる場合、*.la ファイルの削除は API/ABI の変更として取り扱うべきであることに注意してください。例えば、*.la ファイルを削除することは、そのライブラリをリンクする外の世界とのインタフェースを変更します。そして、それは安易に取り掛かる作業ではありません。

静的ライブラリのパッケージング

  • 一般的に、パッケージャはやむを得ない理由がない限り静的ライブラリを提供しないことが強く推奨されます。
  • 我々はどのパッケージが静的ライブラリを使用しているかを追跡できるようにしたいです(つまり、もし静的ライブラリに存在するセキュリティの不具合が修正された場合、どのパッケージをリビルドする必要があるかを見つけることができます)。どの静的ライブラリがパッケージングされているかについて2つのシナリオがあります。
  1. 静的ライブラリと共有ライブラリ。このケースでは、静的ライブラリは *-static サブパッケージに含めなければなりません。*-devel サブパッケージにある他の開発ファイルから静的ライブラリを分離することは、どのパッケージが *-static パッケージを BuildRequire するかをチェックすることによって、静的ライブラリと共有ライブラリを使用していることを追跡するために許容されています。その目的はこのような静的ライブラリから共有ライブラリを使用するように、可能になればいつでもパッケージを変更するためです。
  2. 静的ライブラリのみ。あるパッケージが静的ライブラリのみを提供する場合、全ての静的ライブラリを *-devel サブパッケージに含めることができます。さらに、*-devel に含めるなら、仮想的に *-static パッケージを Provide しなければなりません。
%package devel
Provides: foo-static = %{version}-%{release}

静的ライブラリのバージョンに対して明示的にリンクする必要があるパッケージは、その使用方法を追跡できるように BuildRequire: foo-static しなければなりません。

  • あるパッケージが静的ライブラリを機能として要求する共有ライブラリ(のみ)を持つなら、静的ライブラリは *-devel に含めることができます。その devel パッケージは *-static パッケージのために仮想的に Provide しなければなりません。そして、devel パッケージに依存するパッケージは *-static パッケージを BuildRequire しなければなりません。

実行ファイルを静的にリンクすること

  • 静的リンクは特殊な例外であり、その都度、個別に決定されるべきです。パッケージャは承認をもらうために FESCO に対して、静的リンクをする理由やその優位性も含めて提示しなければなりません、
  • あるライブラリに対して静的リンクするなら、そのライブラリの新バージョンに対してリビルドしたいパッケージのセキュリティ問題やバグ修正を監視できるように、そのライブラリの initialcc リストへあなたの名前を追加してください。そういったリクエストを作成するための手順があります。

FESCo へ伝える必要のないプログラム

  • OCaml で書かれたプログラムは通常 OCaml ライブラリを動的にリンクしません。その仕様のために静的リンクについての要件は断念します。(そうは言っても、C 言語で書かれたライブラリを呼び出す OCaml のコードは、C 言語のライブラリを動的にリンクすべきです。)
  • あるライブラリが静的なバージョンのみを提供するモノに依存するなら、あなたのパッケージは *-static サブパッケージを BuildRequire するように提供されたライブラリに対してリンクすることができます。そういった状況のパッケージャはある共有ライブラリが利用可能になったら、あなたのパッケージが共有ライブラリを使用するために調整すべきなことに気付くべきです。

例外として許可されたプログラム

  • yaboot はファイルシステムを読むために e2fsprogs-libs を使用するブートローダなので静的リンクすることができます。

システムライブラリの重複

システムに存在するライブラリのローカルコピーをパッケージに含めてビルドすべきではありません。そういったパッケージはシステムライブラリを使用するように修正すべきです。こうすることにより、システムのコアライブラリが修正された後でも古いバグやセキュリティホールが残り続けるのを防ぐことができます。パッケージによってはこの内容に対する例外が許可されるかもしれません。詳細については一括りにまとめないライブラリの、関連内容や例外が許可されるためのプロセス、あなたのパッケージを一括りにまとめるならその要求仕様を参照してください。

Rpath に注意する

稀に、(-rpath 又は -R フラッグを使用して)バイナリをリンクするときにコード内に特定のライブラリパスがハードコーディングされます。これは一般的に rpath として参照されます。通常は、動的リンカやローダー(ld.so)が共有ライブラリの実行可能な依存関係を解決して、必要とされるライブラリをロードします。しかし、-rpath 又は -R が使用された場合、そのパス情報はバイナリ内にハードコーディングされていて実行時に ld.so によって調べられます。Linux 動的リンカはハードコーディングされたパスよりも普通は利口に動作するので、Fedora では rpath の使用を通常は許可していません。

rpmdevtools パッケージに含まれる check-rpaths というツールがあります。~/.rpmmacros 設定ファイルの %__arch_install_post マクロに check-rpaths を追加すると良いでしょう。 

%__arch_install_post            \
/usr/lib/rpm/check-rpaths     \
/usr/lib/rpm/check-buildroot

check-rpaths が実行されると次のように出力されるかもしれません。 

ERROR   0001: file '/usr/bin/xapian-tcpsrv' contains a standard rpath '/usr/lib64' in [/usr/lib64]

check-rpaths が検出した全ての rpath は削除 しなければなりません。

内部ライブラリのための Rpath

あるプログラムが内部で使用するライブラリをインストールするとき、大抵はシステムパスにインストールしません。これらの内部ライブラリはパッケージ内のそのプログラムのため(例えば、共通で実行されるコードを取り除くため)にのみ使用されます。また内部ライブラリはパッケージの外部で使用することを想定していません。こういった場合、内部ライブラリを見つけるために rpath を使用してパッケージ内にそのプログラムを含める目的なら許容されます。

例: 

# Internal libraries for myapp are present in:
%{_libdir}/myapp/
%{_libdir}/myapp/libmyapp.so.0.3.4
%{_libdir}/myapp/libmyapp.so

# myapp has an rpath to %{_libdir}/myapp/
readelf -d /usr/bin/myapp | grep RPATH
 0x0000000f (RPATH)                      Library rpath: [/usr/lib/myapp]
非内部ライブラリ
あるパッケージ外部のプログラムがライブラリに対してリンクすることを想定するとき、 Rpath の代替方法、又は単に %{_libdir} 内へライブラリを移動するのが良い方法です。そうすれば、rpath で全てのプログラムにリンクせずに動的リンカがライブラリを見つけることができます。

Rpath の代替方法

あるバイナリが非標準パス(標準パスは /lib, /usr/lib, /lib64, /usr/lib64 です)に存在するライブラリを探すのに rpath がよく使用されます。ライブラリを非標準パス(例えば、/usr/lib/foo/)に格納する場合、/etc/ld.so.conf.d/ にその設定ファイルを含めるべきです。例えば、/usr/lib/foo に libfoo の 32bit ライブラリが存在する場合、/etc/ld.so.conf.d/ に "foo32.conf" というファイルを作成して次のように設定します。 

/usr/lib/foo

同様に 64bit バージョンのファイル(例えば、foo64.conf)を作成することも確認してください(もちろんパッケージが 64bit アーキテクチャをサポートする場合です)。

Rpath を削除する

rpath の問題を修正する方法は幾つかあります。

  • 対象アプリケーションが 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
  • 稀に、コード/Makefile で -rpath 又は -R フラッグが与えられないように取り除くパッチが適用されます。しかし、これは簡単ではなく、適切な方法でもありません。
  • 最終手段として、Fedora には chrpath というパッケージがあります。このパッケージがインストールされる場合、rpath を含むファイルに対して chrpath --delete を実行することができます。先に説明した例であれば次のように実行します。
chrpath --delete $RPM_BUILD_ROOT%{_bindir}/xapian-tcpsrv

最終的にこの方法を使用することに決めたら BuildRequires: chrpath を spec ファイルに追加することを忘れないように注意してください。

設定ファイル

パッケージの設定ファイルはすぐに分かる状態でなければなりません。

大まかな方法として、よく考えて変更することで何かを壊してしまうと推測されない限り、%config の代わりに　%config(noreplace) を使用してください。言い換えれば、パッケージのアップグレード時にローカルでの設定ファイルの変更内容を上書きする前に真剣に考えてください。noreplace を使用しない例としては、新しいリビジョンのパッケージが以前のリビジョンのパッケージの設定ファイルでは動作しないように設定ファイルを変更するときです。%config が使用されているときはいつでも、その理由を説明した簡潔なコメントを spec ファイルに追加してください。

/usr 配下で %config や %config(noreplace) を使用しないでください。Fedora では /usr に設定ファイルを置かないようにしています。

初期化スクリプト

現時点では、Fedora は SystemV スタイルの初期化スクリプトのみをサポートしています。SystemV スタイルの詳細なガイドラインについては Packaging:SysVInitScript を参照してください。

デスクトップファイル

パッケージが GUI アプリケーションを含むなら、適切にインストールされる .desktop ファイルも含める必要があります。このガイドラインの対象となる GUI アプリケーションとは X ウィンドウを描画して、そのウィンドウ内で実行される全てのアプリケーションのことです。インストールされる .desktop ファイルは、Name, GenericName, Categories, StartupNotify エントリの正しい用途を検証することに十分注意を払いながら、desktop-entry-spec に従わなければなりません。

アイコンタグとデスクトップファイル

アイコンタグの指定方法は2通りあります。

  • フルパス指定のアイコンファイル

Icon=/usr/share/pixmaps/comical.png

  • 拡張子なしの短縮名

Icon=comical

アイコンテーミング(デフォルトは .png、次に .svg、最後 .xpm と仮定する)を許容するので拡張子なしの短縮名の方が推奨されます。とは言え、どちらの方法でも良いです。

.desktop ファイルの作成

そのパッケージが自身の .desktop ファイルを持っていなくてインストールしないなら、.desktop ファイルを作成する必要があります。Source(例えば、Source3: %{name}.desktop)として作成した .desktop ファイルを含める、又は spec ファイル内で .desktop ファイルを生成することができます。例えば、.desktop ファイル(comical.desktop)のサンプルは次のようになります。 

[Desktop Entry]
Name=Comical
GenericName=Comic Archive Reader
Comment=Open .cbr & .cbz files
Exec=comical
Icon=comical
Terminal=false
Type=Application
Categories=Graphics;

desktop-file-install の使用方法

ただパッケージに .desktop ファイルを含めるのみだと十分ではありません。spec ファイルの仕様に準拠した安全な .desktop ファイルを保証するために %install セクションで desktop-file-install 又は desktop-file-validate を実行しなければなりません(そして BuildRequires: desktop-file-utils を設定する)。パッケージが .desktop ファイルをインストールしない、又は .desktop ファイルに対して(カテゴリを追加/削除する等の)変更がある場合、desktop-file-install が使用されなければなりません。.desktop ファイルの内容/場所を変更しない場合、desktop-file-validate を使用しても構いません。ここに使用例のサンプルがあります。 

desktop-file-install                                    \
--dir=${RPM_BUILD_ROOT}%{_datadir}/applications         \
%{SOURCE3}

desktop-file-install                                    \
--add-category="AudioVideo"                             \
--delete-original                                       \
--dir=%{buildroot}%{_datadir}/applications              \
%{buildroot}/%{_datadir}/foo.desktop

desktop-file-validate %{buildroot}/%{_datadir}/applications/foo.desktop
  • 新しいパッケージには、vendor タグを .desktop ファイルへ適用してはいけません。vendor タグを使用する既存パッケージは、パッケージのライフサイクルのために継続して使用しなければなりません。この理由はほとんど (.desktop ファイル/パス名をベースとする)menu-editing のためです。

マクロ

ハードコーディングされたディレクトリ名の代わりにマクロ(Packaging:RPMMacros を参照)を使用してください。

Source: 又は Patch: 行の中にマクロを使用することはスタイルの問題です。マクロなしの方が Source: の可読性が良いと考える人がいます。一方、人によってはマクロを使用すると新しいバージョンへアップデートが簡単なので好む人もいます。全てのケースにおいて、spec ファイル内で統一することと、記載した URL が有効かを検証することを覚えておいてください。spectool(rpmdevtools パッケージに含まれる)は URL がマクロを含むかどうかをチェックするのに役立ちます。

もしマクロを含むときに実際の文字列を調べる必要があるなら、rpm コマンドを使用することができます。例えば、実際の Source: の値を調べるには次のように実行します。 

rpm -q --specfile foo.spec --qf "$(grep -i ^Source foo.spec)\n"

%{buildroot} と %{optflags} vs $RPM_BUILD_ROOT と $RPM_OPT_FLAGS の使用

spec ファイル内で rpm の Build Root と最適化フラグを定義する2つのスタイルがあります。

macro style variable style
Build Root %{buildroot} $RPM_BUILD_ROOT
Opt. Flags %{optflags} $RPM_OPT_FLAGS

全てのシナリオで同じ値を取得するので、どちらのスタイルを選択するかについてはどちらでも構いません。一方のスタイルを選択して、パッケージングする際は統一してそのスタイルを使用すべきです。

2つのスタイルを混在させることは、正常には動作しますが、QA やユーザビリティの視点から悪いことです。そして、Fedora パッケージでそれをしてはいけません。

%makeinstall マクロを使用しない理由

Fedora の RPM は %makeinstall マクロを含みますが、それは make install DESTDIR=%{buildroot} が動作するときに使用しては いけません。%makeinstall は DESTDIR の値を利用しない Makefile で動作する一時解決的な方法ですが、%makeinstall を使用することで次の潜在的問題があります。

  • %makeinstall は "make install" の最中に Make 変数セットを上書きして %{buildroot} パスを先頭に追加します。つまり、それは make prefix="%{buildroot}%{_prefix}" libdir="%{buildroot}%{_libdir} ..." を実行することになります。
  • それはエラーになり易い傾向があり、完全な Makefile ではないものに対して実行すると予期せぬ結果を招きます。例えば、変数がインストール時に置き換えると buildroot パスはインストールされたファイルに含まれるかもしれません。
  • "make install" を実行するときに、違う値を持った Make 変数が %build セクションで評価されるので、不必要な誤ったリビルドを引き起こすきっかけになります。
  • あるパッケージが libtool アーカイブを含む場合、壊れた *.la ファイルをインストールしてしまうことを引き起こします。

代替方法として、Fedora パッケージは make DESTDIR=%{buildroot} install 又は make DESTDIR=$RPM_BUILD_ROOT install を使用すべきです。

ソース RPM ビルド時間のマクロ

Summary: と %description にある全てのマクロは SRPM のビルド時に展開される必要があります。SRPM は、そのパッケージの BuildRequires をインストールせずにビルドされるので、spec ファイルの外側で定義されたマクロに依存することは SRPM をビルドした結果として簡単に展開できないマクロが表示されることになります。1つの方法として、最小限の chroot を作成して SRPM をビルドすることでチェックすることができます。 

mock --init
mock --copyin [SRPM] /
mock --shell bash
rpm -ivh [SRPM]
cd /builddir/build/SPECS
rpmbuild -bs --nodeps [SRPM]
rpm -qpiv /builddir/build/SRPMS/[SRPM]

展開できないマクロ(%{foo})、又は消えてしまった情報(when%{?foo} は空文字列に展開されます)がないかについて rpm の出力をチェックしてください。spec ファイルの Summary: と %description でマクロを定義しないことがより簡単な解決方法です。

間違った %_sourcedir の使用方法

Source# として箇条書きのファイルを使用するパッケージは Source# マクロ名でそういったファイルを参照しなければなりません。さらにそういったファイルを参照するために $RPM_SOURCE_DIR 又は %{sourcedir} を使用してはいけません。詳細は Packaging:RPM_Source_Dir を参照してください。

%define よりも %global を優先的に使用する

他のマクロ定義内にローカルに定義されたサブマクロが必要でない限り(とても稀なケースです)、%define の代わりに %global を使用してください。

その理由は、ステートメントを定義する2つのマクロは rpm のネストされたレベルのトップレベルにある場合も同じように動作するからです。

しかし、 %{!?foo: ... } のような構造のネストされたマクロ拡張が使用される場合、%define は論理的にローカルスコープの範囲内のみその定義が有効になるのに対して、%global 定義はグローバルスコープを持ちます。

Fedora12 やそれ以下のリリースでは、rpm に小さなバグがあり、ローカルのマクロ定義は他のイベントが rpm に対して強制的に行わない限りガベージコレクションされません。そのため、そのバグは滅多に発生しませんが、発生するとローカルのマクロ定義の問題の原因を突き止めるのはとても難しいです。%global をデフォルトとして使用することで新たな潜在的なバグを発生させないことに役立ちます。バグ修正内容

ロケールファイルを扱う

パッケージが翻訳ファイルを含むなら、 

BuildRequires: gettext

を追加してください。そうしないと、そのパッケージは buildroot で翻訳ファイルを生成する際にエラーとなるでしょう。

Fedora には %find_lang という rpm マクロがあります。このマクロは(名前から)そのパッケージに属する全てのロケールファイルを配置します。そして、あるファイル内にロケールファイルのリストを保持します。それから、全てのロケールを含めるためにそのファイルを使用することができます。%find_lang は buildroot へ全てのファイルがインストールされた後、spec ファイルの %install セクションで実行されます。%find_lang の正しい構文は、通常は次の通りです。 

%find_lang %{name}

アプリケーションによっては、そのロケールに違う "名前" を使用するかもしれません。そのため、ロケールファイルを探して、どのような名前が使用されているかを確認する必要があるかもしれません。もし myapp.mo という名前だったら、%{name} の代わりに %find_lang へ myapp をオプションとして渡す必要があります。 %find_lang の実行後、ロケールファイルのリストを保持したファイルをアクティブなディレクトリ(デフォルトでは、ソースディレクトリのトップディレクトリ)に生成するでしょう。このファイルは %find_lang マクロへオプションとして渡された名前に基づきます。通常は %{name}.lang という名前になります。 このファイルを使用して %find_lang が検出したロケールファイルを %files リストへ含めます。こうするには、%files で -f パラメータと共に {name}.lang を指定します。 

%files -f %{name}.lang
%defattr(-,root,root,-)
%{_bindir}/foobar
...

もしロケールが存在して %files セクションに -f パラメータを既に指定しているなら、%{name}.lang のコンテンツを -f を指定しているファイルの最後へ単純に追加してください。(もしかすると1ファイルしか %files -f に渡せないかもしれません)

ここに foo.spec の %find_lang の適切な使用例があります。 

...
%prep
%setup -q

%build
%configure --with-cheese
make %{?_smp_mflags}

%install
make DESTDIR=%{buildroot} install
%find_lang %{name}

%clean
rm -rf %{buildroot}

%files -f %{name}.lang
%defattr(-,root,root,-)
%doc LICENSE README
%{_bindir}/foobar

%changelog
* Thu May 4 2006 Tom "spot" Callaway <tcallawa@redhat.com> 0.1-1
- sample spec that uses %%find_lang

%find_lang を使用しなければならない理由

%find_lang を使用することは spec ファイルをシンプルにすることに役立ちます。そして、幾つかの理由でパッケージングの失敗を防ぐことにも役立ちます。

  • 1行で全てのロケールファイルを表すために %{_datadir}/* を使用するパッケージは、ロケールディレクトリの所有権も持つことになりますが、それは許可されていません。
  • ロケールを持つ大半のパッケージは大量のロケールファイルを持っています。%find_lang を使用する方が spec ファイルに次のように記述よりもずっと簡単です。
%{_datadir}/locale/ar/LC_MESSAGES/%{name}.mo
%{_datadir}/locale/be/LC_MESSAGES/%{name}.mo
%{_datadir}/locale/cs/LC_MESSAGES/%{name}.mo
%{_datadir}/locale/de/LC_MESSAGES/%{name}.mo
%{_datadir}/locale/es/LC_MESSAGES/%{name}.mo
...
  • パッケージのバージョンが上がり新たなロケールファイルが追加されると、%find_lang は実行時に自動的に追加されたロケールファイルを含めるようになります。必要以上にロケールに関する内容で spec ファイルを更新する必要はありません。

ロケールを含むパッケージでは %find_lang を使用しなければならないことを忘れないでください。

タイムスタンプ

spec ファイルでファイルをコピーするコマンドを追加するとき、ファイルのタイムスタンプを保持するコマンドを使用するように考慮してください。例えば、cp -p か install -p になります。

ソースやパッチ等をダウンロードするときは、アップストリームのタイムスタンプを保持するダウンロードツールを使用するように考慮してください。例えば、wget -N か curl -R になります。wget の設定をグローバルに有効にするには、~/.wgetrc に timestamping = on を追加してください。同様に、curl には ~/.curlrc に -R を追加してください。

並行 make

できるだけ make の起動は次のようにすべきです。 

make %{?_smp_mflags}

これは一般的にビルド処理が速くなります。特に SMP マシン上で速くなります。

しかし、並行ビルドをサポートしない make ファイルもあるのでパッケージがこの方法で効率良くビルドできるかを確認してください。そのため、~/.rpmmacros ファイルに 

%_smp_mflags -j3

を追加する必要があるかを考慮すべきです。UP マシン上では、この設定がエラーの大半になります。

スクリプトレット

Fedora パッケージ内でスクリプトレットを使用する場合、本当に慎重になって扱うべきです。スクリプトレットが使用されるとき、それは適切に動作するものでなければなりません。Packaging:ScriptletSnippets に一般的なスクリプトレットについて記載されています。

スクリプトレットの要求仕様

スクリプトレットの依存関係のために Requires(pre,post) スタイルの記述方法を使用しないでください。というのは RPM に2つのバグがあるからです。その代わりに、次のように分割して記述すべきです。 

Requires(pre): ...
Requires(post): ...

詳細は www.redhat.com を参照してください。

特定状況でのみのスクリプトレットの実行

rpm コマンドがあるパッケージのスクリプトレットを実行するとき、その動作がインストール、削除、アップグレード、又は再インストールのどれかで、次のようにスクリプトに対して与えられる整数の引数が変わります。 

          install   erase   upgrade  reinstall
%pre         1        -         2         2
%post        1        -         2         2
%preun       -        0         1         -
%postun      -        0         1         -

例えば、chkconfig コマンドで初期化スクリプトをインストールするパッケージは、アップグレードではなく削除のみを行う場合は次のようなスニペットでアンインストールすべきです。 

%preun
if [ $1 -eq 0 ] ; then
/sbin/chkconfig --del %{name}
fi

また様々なスクリプトに渡される整数値について、公式の、汎用的な定義は /usr/share/doc/rpm-*/triggers も参照してください。

特定ディレクトリに書き込みのみが許可されているスクリプトレット

次の表にある /tmp, /var/tmp (又は rpmbuild プロセスによってセットされる $TMPDIR や %{_tmppath})といった有効な一時ファイル置き場や %{buildroot}, %{_builddir} 配下にあるファイル(作成、変更、削除)のみを変更するパッケージのスクリプト(%prep, %build, %install, %check と %clean)を構築してください。

/tmp, /var/tmp, $TMPDIR, %{_tmppath} %{_builddir} %{buildroot}
%prep yes yes no
%build yes yes no
%install yes yes yes
%check yes yes no
%clean yes yes yes

厳密に補足すると、ビルドを実行するユーザの uid に関係なくこの表の通りになるようにすべきです。

条件付きの依存関係

rpmbuild への --with(out) foo のオプション引数が存在して、条件によって選択される依存関係を spec ファイルに含む場合、デフォルトオプション、つまり、rpmbuild のコマンドラインにこのような引数が与えずに実行されるようにソース RPM をビルドするようにしてください。その理由はそういった要件は結果的にはソース RPM の中に "含めるようにする" からです。つまり、spec ファイルの条件で適用するものではありません。

別のユーザアカウントでパッケージをビルドする

あなたが完全なセキュリティ監査を実施しない状態でソフトウェアをビルドする場合、別のユーザアカウントを使用して自身の機密情報を保護してください。機密情報とは、例えば、あなたの GPG 秘密鍵のような情報を指します。

機密情報の保護についてはレビューアやテスターにも当てはまります。いかなる機密情報にもアクセスできない別のユーザアカウントで src.rpms をリビルドしてください。

再配置可能なパッケージ

再配置可能なパッケージを生成するために RPM の仕組みを利用しようと思うと本当にがっかりします。適切に動作させるのが難しく、yum 又はインストーラーから使用するのは不可能であり、他のパッケージガイドラインに従うなら一般的には必要ないからです。到底起こりそうもないことですが、パッケージを再配置可能な状態にするに足る理由があるなら、パッケージレビューでその要件の意図と理由をはっきりと説明しなければなりません。

コード Vs コンテンツ

コンピュータの実行可能なコードとコンテンツを区別するのは重要です。(もちろん、オープンソース互換ライセンスであり、法的な問題がない等を前提として)コードが許容されるのに対して、コンテンツは数種類のみが許容されます。

そのルールは次のようになります。

コンテンツが OS のユーザエクスペリエンスを拡張するなら、そのコンテンツは Fedora へパッケージングして良いです。例えば、フォント、テーマ、クリップアートや壁紙のようなコンテンツになります。

それでもコンテンツは含めて良いかどうかをレビューされる必要があります。オープンソース互換ライセンスである必要があり、法的な問題があってはいけません。さらに、コンテンツには追加の制約があります。

  • コンテンツはアニメ、擬似的、写真であるかによらずポルノ又はヌードであってはいけません。
  • コンテンツは不快で、差別や名誉を毀損するようなものであってはいけません。コンテンツの一部がそれに該当するかどうかよく分からないなら、それはおそらく該当します。
  • 全てのコンテンツは含めることが可能かどうかの最終決定権を持つ FESCo によってレビューされて従わなければなりません。

許容されるコンテンツ例は次の通りです。

  • パッケージのドキュメント、又はヘルプファイル
  • Office 製品に使用されるクリップアート
  • 背景画像(不快な気分や差別にならない、フリーに再配布可能)
  • フォント(所有権や法的な懸念事項がないオープンソースライセンス)
  • ゲームレベルはコンテンツと見なされません
  • プログラム又はテーマ(又はドキュメント)が使用するソースの tar ボールに含まれるサウンド又はグラフィックは許容されます
  • そのフォーマットに特許がなくコンテンツがフリーに制約なく配布できる限り、ゲーム音楽コンテンツは許容されます
  • ソースの tar ボールに含まれるサンプルファイルコンテンツとは見なされません

許容されないコンテンツ例は次の通りです。

  • マンガ本のファイル
  • 宗教に関するテキスト
  • mp3 ファイル(専売特許のある)

どんなコンテンツが許容されるかよく分からないなら、fedora-devel-list で尋ねてください。

ファイルとディレクトリの所有者

パッケージは %install セクションでインストールされる全てのファイルを所有すべきです。そして、パッケージは他のパッケージが既に所有しているファイルを所有してはいけません。基本原則として最初にインストールされるパッケージが、他のパッケージがそのファイルの存在に依存する可能性があるファイルを所有すべきです。例えば、これは filesystem 又は man パッケージによって所有されるファイルであっても所有権を共有するようなパッケージは Fedora にはないということです。もし他のパッケージが所有しているファイルを所有するための適切な理由があるなら、パッケージレビューのときに連絡してください。

ディレクトリの所有者はファイルの所有者よりも少し複雑です。パッケージは自分が追加したファイルがある全てのディレクトリを所有しなければなりません。但し、次のディレクトリは除外されます。

  • filesystem や man 又はその他に明示的に作成された -filesystem が所有するディレクトリ
  • パッケージの自然な依存関係のつながりで他のパッケージが所有するディレクトリ

この文脈で言う、パッケージの "自然な依存関係のつながり" というのは、普通にそのパッケージが機能を提供するために必要なパッケージセットと定義されます。具体的に言うと、あなたのパッケージが追加するファイルのディレクトリを所有するという、ただそれだけのためにパッケージを要求する必要はありません。また、もしあなたのパッケージが別の理由でそのパッケージを既に要求しているなら、そのディレクトリを所有すべきではありません。

全てのケースにおいて、システム上に存在するどのパッケージにも所有されていないディレクトリは保護しています。詳細は Packaging:UnownedDirectories を参照してください。

複数パッケージが所有することの注意
複数パッケージが共通のディレクトリを所有する場合、全てパッケージでそのディレクトリの所有者とパーミッションが一致していることを保証しなければならないことに注意してください。

ほとんどのディレクトリの所有に関連するケースにおいて、どのように取り扱うかを例で説明します。

パッケージ全体に含まれる、又はコア機能によって使用されるディレクトリ

例: 

gnucash は /usr/share/gnucash directory 配下に多くのファイルを置きます

解決方法: gnucash パッケージは /usr/share/gnucash ディレクトリを所有すべきです

要求されたパッケージの機能を実装するパッケージにも所有されるディレクトリ

例: 

pam は /etc/pam.d directory を所有します
gdm は /etc/pam.d 配下にファイルを置きます

解決方法: pam パッケージは /etc/pam.d ディレクトリを所有すべきです。そして、gdm は Require: pam とします。

あなたのパッケージが機能を提供するために必要ではないパッケージがディレクトリを所有する

Some packages create and own directories with the intention of permitting other packages to store appropriate files, but those other packages do not need that original package to be present to function properly.

適切なファイルを格納するために他のパッケージを許容する目的でディレクトリを作成、所有しますが、そういった他のパッケージは正常に機能を提供するためにそのオリジナルのパッケージを必要としません。

例: 

gtk-doc は /usr/share/gtk-doc/ を所有します
evolution は /usr/share/gtk-doc/ にファイルを置きます
evolution は正常に機能を提供するために gtk-doc を必要としません
evolution の依存関係の繋がりには /usr/share/gtk-doc/ を所有するパッケージはありません

解決方法: evolution パッケージは /usr/share/gtk-doc ディレクトリを所有すべきです。gtk-doc をディレクトリの所有権のためだけに明示的に Require: へ追加する必要はありません。

例外
稀に mozilla-filesystem のように、"見せかけのファイルシステム" が所有するようなディレクトリの方が望ましいこともあるでしょう。これらのパッケージは他のパッケージがそのディレクトリへファイルを格納する際に明示的に要求するように設計されます。このような状況では、見せかけのファイルシステムパッケージを明示的に Require: へ追加すべきであり、そういったディレクトリを複数のパッケージが所有すべきではありません。パッケージャは、見せかけのファイルシステムパッケージを作成するかを決めるときに影響のあるディレクトリやパッケージの数を考慮すべきです。そして、必要かどうかの最善の判断を自分で行います。

別の例: 

bash-completion は /etc/bash_completion.d ディレクトリを所有して、そこに置かれたファイルを自身の設定のために使用します。
git は /etc/bash_completion.d にファイルを置きます
bzr は /etc/bash_completion.d にファイルを置きます

解決方法: git と bzr パッケージの両方とも bash-completion がオプション機能であるかのように /etc/bash_completion.d ディレクトリを所有すべきです。そして、git や bzr のインストールは bash-completion のインストールを強制しないようにします。

基本原則
この例外が適用されるかどうかを決定するとき、パッケージャとレビューアはこの質問をすべきです。この共通ディレクトリに存在するそのファイルは他のパッケージに対して機能を追加したり、拡張したりしますか？ここで他のパッケージはこのパッケージの主機能を提供するのに必要ではありません。

あるディレクトリの提供に依存するパッケージは、その後のバージョンで違うディレクトリを所有するように変更されるかもしれません、そして、あなたのパッケージはその後のバージョンで何の変更もなく実行されます

一般的な例の1つとして Perl モジュールがあります。

perl-A-B が perl-A に依存して、/usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi/A/B にファイルをインストールすると仮定してください。ベースとなる Perl パッケージはバージョン 5.8.8 で互換性を維持する限り /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi を所有することを保証します。しかし、将来 perl-A パッケージのアップグレードパッケージが /usr/lib/perl5/vendor_perl/5.9.0/i386-linux-thread-multi/A (このディレクトリを所有する)にファイルをインストールするかもしれません。そのため、perl-A-B パッケージは適切な所有者情報を維持するために /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi/A/B と同様に /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi/A を所有する必要があります。

ユーザとグループ

パッケージによってはユーザとグループの両方またはどちらか一方を実行時に指定するように要求したり、又はその方が利点があったりするものがあります。そういったケースを扱うガイドラインはユーザとグループにあります。

ウェブアプリケーション

Fedora のウェブアプリケーションは /var/www/ の中ではなく、/usr/share/%{name} の中にコンテンツを保存すべきです。その理由は以下になります。

  • /var は様々なデータファイルやログの保存をサポートしています。コンテンツは /usr/share の方がより適切です。
  • 多くのユーザは既に /var/www にコンテンツを保存しています。どのような Fedora パッケージにおいても /var/www のトップに誤って上書きしてしまうようなことは望んでいません。
  • /var/www は今ではファイルシステム階層標準(FHS)ではありません。

競合

できるだけ Fedora パッケージはお互いに競合しないようにすべきです。しかし、不幸にも常にそうであるとは限りません。Fedora の競合ポリシーの詳細については 競合 を参照してください。

また、代替ツールや環境モジュールのようなツールもパッケージが競合しないように使用することができます。

代替ツール

代替ツールは、シンボリックリンクセットを維持することで同じ機能を提供するパッケージの並行インストールを行う方法を提供します。代替ツールの使用方法の詳細については代替ツールを参照してください。

環境モジュール

それぞれがユーザのニーズを提供していて、且つ同時に利用可能でなければならない複数の要因がある場合、システム全体に渡るので代替ツールは十分ではありません。そのような状況では、環境モジュールを使用すると競合を避けることができます。環境モジュールの使用方法の詳細については環境モジュールを参照してください。

拡張カーネルモジュールはありません

ある時点(Fedora8 以前)までは、"アドオン" カーネルモジュールを含むパッケージは許可されていました。今後はもはやそうではありません。Fedora はカーネルモジュールのパッケージャへ、そのコードをアップストリームのカーネルツリーへ取り込まれるように提案することを強く推奨します。

既存のカーネルモジュールパッケージは Fedora9 の前に削除(又はカーネルパッケージ内にマージ)されなければなりません。

"kmod" スタイルのカーネルモジュールのパッケージング方法に関するリファレンスドキュメントはここに保存されています。

/srv 配下のファイルやディレクトリはありません

FHS によると 

"/srv 配下の階層における特定サブディレクトリが存在していることや /srv 内に格納しなければならない
データに依存するようなプログラムはありません。しかし、/srv は FHS 準拠のシステムとしては存在する
必要があるので、データのためにデフォルトの場所として使用されるべきです。

Linux ディストリビューションは、管理者権限なしで /srv 配下に置かれたファイルを削除しないように
注意しなければなりません。"

/srv は FHS のセクションとしては曖昧な実装であり、その意図された使用方法はよく分かりません。現時点では、Fedora のパッケージは /srv 配下にファイルやディレクトリを置くことはできません。

Fedora パッケージをインストールしてユーザが実行したら /srv はデータのためのデフォルトの場所として使用できるということに注意しなくてはいけません。但し、パッケージは /srv 配下にあるディレクトリやファイルを所有してはいけません。

複数プロジェクトのビルド

Fedora パッケージは1つのパッケージ内に複数の、独立した、アップストリームのプロジェクトをまとめて含めないように最大限の努力をするべきです。

他のパッケージにあるフォントを1つにまとめない

Type1、OpenType TT (TTF) や OpenType CFF (OTF) のような汎用フォーマットのフォントは特殊なパッケージングガイドライン(1)に従います。そういったフォントは、個別のアプリケーションディレクトリではなく、システム全体のフォントリポジトリにパッケージングされます。 詳細についてはPackaging:FontsPolicy#Package_layout_for_fontsを参照してください。

全てのパッチはアップストリームのバグへのリンクかコメントを持つようにする

Fedora の spec ファイルに含まれる全てのパッチは、そのパッチの上にアップストリームの状況に関するコメントを 記載するべき です。パッチを作成するときは常に、作成したパッチをアップストリームのバグトラッカーへ登録するようにするのがベストプラクティスです。そして、そのパッチの上にコメントとして、バグトラッカーのバグ情報へのリンクを含めます。例えば、次の通りです。 

# http://bugzilla.gnome.org/show_bug.cgi?id=12345
Patch0: gnome-panel-fix-frobnicator.patch

この例の記載内容で全く問題はありません。しかし、もっと良いのは、バグトラッカーのリンクの上にそのパッチがどういったものかの簡潔なコメントがあると分かり易いです。 

# Don't crash with frobnicator applet
# http://bugzilla.gnome.org/show_bug.cgi?id=12345
Patch0: gnome-panel-fix-frobnicator.patch

アップストリームへパッチを送ることやこのコメントを追加することは、Fedora が良い FLOSS 市民(なぜアップストリーム？を参照)であることの証明になります。そうすることで、他の人(やあなたも)がアップストリームの新たなリリースで適用されそうなパッチがどういったものかを知ることによって、完全なパッケージメンテナンスを維持することに役立ちます。

アップストリームがバグトラッキングシステムを持っていない場合

アップストリームへパッチを送ったという事実とその状況を提示しましょう。 

# Sent upstream via email 20080407
Patch0: foobar-fix-the-bar.patch

# Upstream has applied this in SVN trunk
Patch0: foobar-fix-the-baz.patch

Fedora に特化した(アップストリームで拒否された)パッチ

パッチによっては Fedora に特化した修正もあるかもしれません。そのような場合は次のように記載します。 

# This patch is temporary until we land the long term System.loadLibrary fix in OpenJDK
Patch0: jna-jni-path.patch

Epoch の使用

RPM の Epoch タグは、できるだけ使用しないようにすべきで、最後の手段としてのみ使用されます。とは言え、アップストリームのバージョン番号ルールの変更、又はサードパーティリポジトリから簡単に移行するために Epoch を使用するなど必要になるときがあります。

サードパーティリポジトリの Epoch

あるパッケージがインポートされる、又は既にリポジトリで公開されていた場合、パッケージャはサードパーティパッケージの最新バージョンと同じ Epoch タグを任意で設定することができます。

シンボリックリンク

シンボリックリンクを作成するときに相対パスか絶対パスかのどちらかで作成することができます。Fedora では、どちらか一方の方法のみに限定していません。パッケージャはシンボリックリンクの作成について必要なときに最適な方法を選択すべきです。

相対パスのシンボリックリンク

相対パスのシンボリックリンクはファイルやディレクトリを相対パスで指すシンボリックリンクです。例えば、次のコマンドは相対パスのシンボリックを作成します。 

ln -s ../..%{_bindir}/foo %{buildroot}/bin/foo

良い点:

  • 相対パスのシンボリックリンクは chroot の内外で同じファイルを指します。

悪い点:

  • 絶対パスのシンボリックリンクの作成と比較するとずっと複雑です。
  • 相対パスのシンボリックリンクはファイルシステムの一部が特別な場所にマウントされていると壊れたり、予想もしない動作を引き起こす可能性があります
  • 相対パスのシンボリックリンクはバインドマウントやディレクトリを指すときに壊れる可能性があります
  • 相対パスのシンボリックリンクの作成に rpm のシステムマクロを使用するのはかなり難しいです。

絶対パスのシンボリックリンク

絶対パスのシンボリックリンクはファイルやディレクトリを絶対パスで指すシンボリックリンクです。例えば、次のコマンドは絶対パスのシンボリックリンクを作成します。 

ln -s %{_bindir}/foo %{buildroot}/bin/foo

良い点:

  • 相対パスのシンボリックリンクの作成と比較すると簡単です。
  • 絶対パスのシンボリックリンクはバインドマウントやディレクトリを指すときに正常に動作します。
  • rpm のシステムマクロを使用して正常に動作します。

悪い点:

  • 絶対パスのシンボリックリンクは chroot を使用すると壊れる可能性があります。

man ページ

man ページは unix システムにおけるヘルプを見る伝統的な方法です。パッケージの全てのバイナリ/スクリプトのために man ページを作成すべきです。もし man ページがないなら、アップストリームで man ページを追加するように働きかけてください。時々、他のディストリビューション(特に Debian)では、man ページで問題が発生します。そういったことに遭遇したら、問題解決のための出発点にしましょう。

アプリケーションに特化したガイドライン

Packaging:Namespace に個々のページを持つアプリケーションに特化したガイドラインがあります。

Eclipse

Eclipse プラグインパッケージのためのガイドライン: Packaging:EclipsePlugins

Emacs

Emacs/X-Emacs パッケージのためのガイドライン: Packaging:Emacs

Fonts

font パッケージのためのガイドライン: Packaging:FontsPolicy

Fortran

Fortran パッケージのためのガイドライン: Packaging:Fortran

Globus Toolkit

Globus Toolkit のパッケージのためのガイドライン: Packaging:Globus

Haskell

Haskell パッケージのためのガイドライン: Packaging:Haskell

Java

java パッケージのためのガイドライン: Packaging:Java

Lisp

lisp パッケージのためのガイドライン: Packaging:Lisp

Mono

Mono パッケージのためのガイドライン: Packaging:Mono

MPI

MPI パッケージのためのガイドライン: Packaging:MPI

OCaml

OCaml パッケージのためのガイドライン: Packaging:OCaml

OpenOffice.org

OpenOffice.org の拡張パッケージのためのガイドライン: Packaging:OpenOffice.orgExtensions

Perl

Perl パッケージのためのガイドライン: Packaging:Perl

PHP

PHP パッケージのためのガイドライン: Packaging:PHP

Python

Python アドインモジュールのためのガイドライン: Packaging:Python

R

R モジュールパッケージのためのガイドライン: Packaging:R

Ruby

Ruby パッケージのためのガイドライン: Packaging:Ruby

Sugar

Sugar Activity パッケージのためのガイドライン: Packaging:SugarActivityGuidelines

Tcl/Tk

Tcl/Tk 拡張パッケージのためのガイドライン: Packaging:Tcl

Wordpress

Wordpress 拡張パッケージのためのガイドライン: Packaging:WordPress plugin packaging guidelines

Retrieved from "https://fedoraproject.org/w/index.php?title=Packaging/Guidelines/ja&oldid=528458"