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

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

パッケージを作成していて、そのパッケージがガイドラインの一部の内容に従う必要はないと思ったら、どうか 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.

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

Packages should not use the PreReq tag. Once upon a time, in dependency loops PreReq used to "win" over the conventional Requires when RPM determined the installation order in a transaction. This is no longer the case.

ファイルの依存関係

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.

明示的な 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. Modern package management tools are capable of resolving such dependencies to determine the required packages. Explicit dependencies on specific package names may aid the 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:

  # The automatic dependency on libfubar.so.1 is insufficient,
  # as we strictly need at least the release that fixes two segfaults.
  Requires: libfubar >= 0:1.2.3-7

Packagers should revisit an explicit dependency as appropriate to avoid 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 をフィルタリングすること

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

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.

Before adding BuildRequires to any package, please be comfortable with Requires .

There are two suggested ways of detecting missing BuildRequires. 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 rpmdev-rmdevelrpms section to find out more.
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. MockTricks page contains more information. Another mock-like tool, mach is also available in the Fedora repository.

rpmdev-rmdevelrpms

rpmdev-rmdevelrpms script within the rpmdevtools toolkit is a script written by Ville Skyttä that helps RPM packagers in finding missing BuildRequires. Simply run it and allow it to remove all *-devel packages and build tools like this example.

[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.

Then attempt to build your RPM package. Use yum to reinstall any packages that are already in BuildRequires. If your build fails after this point, then you need to read through the build process and ascertain the missing BuildRequires from the error messages within.

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.

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...)

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.

例外事項

There is no need to include the following packages or their dependencies as BuildRequires because they would occur too often. These packages are considered the minimum build environment.

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

要約とパッケージ説明内容

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.

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

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
GOOD: A word-processor with support for Microsoft Office DOC files

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.

文字エンコーディング

Unless you need to use characters outside the 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 this chart .

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.

ドキュメント

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 *-doc as the subpackage name, and Documentation as the value of the Group tag.

Also, if a package includes something as %doc, it must not affect the runtime of the application. To summarize: If it is in %doc, the program must run properly if it is not present.

コンパイラフラッグ

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.

Debuginfo パッケージ

Packages should produce useful -debuginfo packages, or explicitly disable them when it is not possible to generate a useful one but rpmbuild would do it anyway. Whenever a -debuginfo 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 .

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.

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.

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 Guidelines.

ベースパッケージの要求

Devel packages must require the base package using a fully versioned dependency: Requires: %{name} = %{version}-%{release}. Usually, subpackages other than -devel should also require the base package using a fully versioned dependency.

共有ライブラリ

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 %post and %postun. If the package has multiple subpackages with libraries, each subpackage should also have a %post/%postun section that calls /sbin/ldconfig. An example of the correct syntax for this is:

%post -p /sbin/ldconfig

%postun -p /sbin/ldconfig

Note that this specific syntax only works if /sbin/ldconfig is the only call in %post and %postun. If you have additional commands to run during the scriptlet, call /sbin/ldconfig at the beginning of the scriptlet, like this:

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

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

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

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.

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

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 BuildRequire 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:

%package devel
Provides: foo-static = %{version}-%{release}

Packages which explicitly need to link against the static version must BuildRequire: foo-static, so that the usage can be tracked.

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 BuildRequire the *-static package.

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

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 instructions for making that request.

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.)

If a library you depend on only provides a static version your package can link against it provided that you BuildRequire 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.

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

yaboot has permission to link statically since it's a boot loader that uses e2fsprogs-libs to read the filesystem

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

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 No Bundled Libraries page.

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 %__arch_install_post macro in your ~/.rpmmacros config file:

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

When check-rpaths is run, you might see output like this:

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

Any rpath flagged by check-rpaths MUST be removed.

内部ライブラリのための 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.

Example:

# 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]

Non-Internal Libraries
When programs outside of the package are supposed to link against the library, it is better to use the 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.

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:

/usr/lib/foo

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).

Rpath を削除すること

There are several different ways to fix the rpath issue:

If the application uses configure, try passing the --disable-rpath flag to configure.
If the application uses a local copy of libtool, add the following lines to the spec after %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

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.
As a last resort, Fedora has a package called chrpath. When this package is installed, you can run chrpath --delete on the files which contain rpaths. So, in our earlier example, we'd run:

chrpath --delete $RPM_BUILD_ROOT%{_bindir}/xapian-tcpsrv

Make sure that you remember to add a BuildRequires: chrpath if you end up using this method.

設定ファイル

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

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

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

初期化スクリプト

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

デスクトップファイル

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 desktop-entry-spec , paying particular attention to validating correct usage of Name, GenericName, Categories , StartupNotify entries.

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

The icon tag can be specified in two ways:

Full path to specific icon file:

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

Short name without file extension:

Icon=comical

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.

.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 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 の使用方法

It is not simply enough to just include the .desktop file in the package, one MUST run desktop-file-install OR desktop-file-validate in %install (and have BuildRequires: desktop-file-utils), to help ensure .desktop file safety and spec-compliance. desktop-file-install 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). desktop-file-validate MAY be used instead if the .desktop file's content/location does not need modification. Here are some examples of usage:

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

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).

マクロ

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.

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:

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

%{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:

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

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.

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

Fedora's RPM includes a %makeinstall 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:

%makeinstall 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: make DESTDIR=%{buildroot} install or make DESTDIR=$RPM_BUILD_ROOT install

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

All macros in Summary: and %description 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:

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]

Check the rpm output for unexpanded macros (%{foo}) or missing information (when%{?foo} is expanded to the empty string). Even easier is to simply avoid macros in Summary: and %description unless they are defined in the current spec file.

%define よりも優先される %global

Use %global instead of %define, unless you really need only locally defined submacros within other macro definitions (a very rare case).

Rationale: The two macro defining statements behave the same when they are a the top level of rpm's nesting level.

But when they are used in nested macro expansions (like in %{!?foo: ... } constructs, %define theoretically only lasts until the end brace (local scope), while %global definitions have global scope.

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 %global by default helps to avoid creation of new latent bugs. Bugfix description

ローカルファイルを扱うこと

If the package includes translations, add

BuildRequires: gettext

If you don't, your package could fail to generate translation files in the buildroot.

Fedora includes an rpm macro called %find_lang. 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. %find_lang 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 %find_lang is usually:

%find_lang %{name}

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 myapp.mo, then you will need to pass myapp to %find_lang instead of %{name}. After %find_lang 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 %find_lang macro. Usually, it will be named %{name}.lang. You should then use this file in the %files list to include the locales detected by %find_lang. To do this, you should include it with the -f parameter to %files.

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

If you are already using the -f parameter for the %files section where the locales should live, just append the contents of %{name}.lang to the end of the file that you are already using with -f. (Note that only one file may be used with %files -f.)

Here is an example of proper usage of %find_lang, in foo.spec:

...
%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 を使用する必要がある理由

Using %find_lang helps keep the spec file simple, and helps avoid several other packaging mistakes.

Packages that use %{_datadir}/* to grab all the locale files in one line also grab ownership of the locale directories, which is not permitted.
Most packages that have locales have lots of locales. Using %find_lang is much easier in the spec file than having to do:

%{_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
...

As new locale files appear in later package revisions, %find_lang will automatically include them when it is run, preventing you from having to update the spec any more than is necessary.

Keep in mind that usage of %find_lang in packages containing locales is a MUST.

タイムスタンプ

When adding file copying commands in the spec file, consider using a command that preserves the files' timestamps, eg. cp -p or install -p.

When downloading sources, patches etc, consider using a client that preserves the upstream timestamps. For example wget -N or curl -R. To make the change global for wget, add this to your ~/.wgetrc: timestamping = on, and for curl, add to your ~/.curlrc: -R.

並列に make

Whenever possible, invocations of make should be done as

make %{?_smp_mflags}

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_mflags -j3

to your ~/.rpmmacros file -- even on UP machines -- as this will expose most of these errors.

スクリプトレット

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.

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

Do not use the Requires(pre,post) style notation for scriptlet dependencies, because of two bugs in RPM. Instead, they should be split like this:

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

For more information, see www.redhat.com .

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

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:

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

This means that for example a package that installs an init script with the chkconfig command should uninstall it only on erase and not upgrade with the following snippet:

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

See also /usr/share/doc/rpm-*/triggers, which gives a more formal, generalized definition about the integer value(s) passed to various scripts.

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

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, $TMPDIR, %{_tmppath}	%{_builddir}	%{buildroot}
%prep	yes	yes	no
%build	yes	yes	no
%install	yes	yes	yes
%check	yes	yes	no
%clean	yes	yes	yes

Further clarification: That should hold true irrespective of the builder's uid.

条件付きの依存関係

If the spec file contains conditional dependencies selected based on presence of optional --with(out) foo arguments to rpmbuild, build the source RPM to be submitted with the default options, ie. so that none of these arguments are present in the rpmbuild command line. The reason is that those requirements get "serialized" into the resulting source RPM, ie. the conditionals no longer apply.

ユーザアカウントを分離したパッケージのビルド

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.

再配置可能なパッケージ

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.

コード 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.

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.

Some examples of content which is permissable:

Package documentation or help files
Clipart for use in office suites
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.
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.

Some examples of content which are not permissable:

Comic book art files
Religious texts
mp3 files (patent encumbered)

If you are unsure if something is considered approved content, ask on fedora-devel-list.

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

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 filesystem or man 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.

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.

Note on multiple ownership
Note that when co-owning directories, you must ensure that the ownership and permissions on the directory match in all packages that own it.

Note on directories
If a directory is explicitly required by packages in Fedora (such as /usr/lib/mozilla/plugins), 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.

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

An example:

gnucash places many files under the /usr/share/gnucash directory

Solution: the gnucash package should own the /usr/share/gnucash directory

巨大な環境インフラの一部になる多くのディレクトリに存在するファイルを置くパッケージ

An example:

kdeutils places files in (among other places)
 /usr/share/applications/kde4
 /usr/share/kde4/apps
 /usr/share/kde4/services

Solution: the infrastructure directories above should be placed in a kde-filesystem package, and kdeutils should Require: the kde-filesystem package.

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

An example:

pam owns the /etc/pam.d directory
gdm places files into /etc/pam.d

Solution: the pam package should own the /etc/pam.d directory, and gdm should Require: the pam package.

複数パッケージが共通ディレクトリにあるファイルを所有するが、それらのファイルは他のパッケージを要求する必要がない

An example:

bash-completion owns the /etc/bash_completion.d directory and uses the files placed there to configure itself.
git places files into /etc/bash_completion.d
bzr places files into /etc/bash_completion.d

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.

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?

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

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.

重複したファイル

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.

ファイルパーミッション

Permissions on files must be set properly. Executables should be set with executable permissions, for example. Every %files section must include a %defattr(...) line. Here is a good default:

%files
%defattr(-,root,root,-)

Unless you have a very good reason to deviate from that, you should use %defattr(-,root,root,-) for all %files sections in your package.

ユーザとグループ

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

ウェブアプリケーション

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

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

競合

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 .

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.

環境モジュール

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.

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

The Packaging:KernelModules page used to be transcluded into the main guidelines page. Instead its contents have been pasted there.

If you're seeing this page, you really should be looking here instead.

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

The FHS says :

"...no program should rely on a specific subdirectory structure of /srv existing
or data necessarily being stored in /srv. However /srv should always exist on 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
directories without administrator permission."

/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.

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 packages should make every effort to avoid having multiple, separate, upstream projects bundled together in a single package.

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

Fonts in general-purpose formats such as Type1, OpenType TT (TTF) or OpenType CFF (OTF) are subject to specific packaging guidelines (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.

全てのパッチはアップストリームのバグへのリンクやコメントを持つべきであること

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:

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

The above is perfectly acceptable; but if you prefer, a brief comment about what the patch does above can be helpful:

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

Sending patches upstream and adding this comment will help ensure that Fedora is acting as a good FLOSS citizen (see 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.

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

You can indicate that you have sent the patch upstream and any known status:

# 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 に特化した(アップストリームで拒否された)パッチ

It may be that some patches truly are Fedora-specific; in that case, say so:

# 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 タグを任意で設定することができます。

シンボリックリンク

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.

廃止されたシンボリックリンク

An absolute symlink is a symlink which points to an absolute file or directory path. For example, this command would create an absolute symlink:

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

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.

Cons:

Absolute symlinks may break when used with chroots.

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

Search

Packaging/Guidelines/ja

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

名前付け

バージョンとリリース

法律

ライセンス

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

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

例外事項

Spec ファイルの読み易さ

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

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

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

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

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

libexecdir

rpmlint の使用

rpmlint エラー

Changelogs

タグ

BuildRoot タグ

%clean

Requires

PreReq

ファイルの依存関係

明示的な Requires

自動生成された Requires をフィルタリングすること

BuildRequires

rpmdev-rmdevelrpms

例外事項

要約とパッケージ説明内容

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

文字エンコーディング

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

ドキュメント

コンパイラフラッグ

Debuginfo パッケージ

Devel パッケージ

Pkgconfig ファイル

ベースパッケージの要求

共有ライブラリ

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

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

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

FESCo へ知らせる必要のないプログラム

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

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

Rpath に気を付けること

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

Rpath に代わるもの

Rpath を削除すること

設定ファイル

初期化スクリプト

デスクトップファイル

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

.desktop ファイルの作成

desktop-file-install の使用方法

マクロ

%{buildroot} と %{optflags} vs $RPM_BUILD_ROOT と $RPM_OPT_FLAGS を使用すること

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

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

%define よりも優先される %global

ローカルファイルを扱うこと

%find_lang を使用する必要がある理由

タイムスタンプ

並列に make

スクリプトレット

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

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

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

条件付きの依存関係

ユーザアカウントを分離したパッケージのビルド

再配置可能なパッケージ

コード Vs コンテンツ

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

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

巨大な環境インフラの一部になる多くのディレクトリに存在するファイルを置くパッケージ

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

複数パッケージが共通ディレクトリにあるファイルを所有するが、それらのファイルは他のパッケージを要求する必要がない