DeveloperWiki:パッチ

パッチ

このポリシーは *提案* することを目的としていて、強制ではありません。

バニラパッケージ

Arch は可能な限り元の作者の意図の通りにパッケージを提供しようとしています。これは、パッチを追加するときは毎回彼らの意図から一歩ずつ外れていくということを意味します。加えて、たくさんのパッケージを管理していると、パッチの維持は困難になります。

パッチが許される場合

いくつかのソフトウェアで機能させるために修正が必要になることは避けられません。

• *ビルドシステム* へのパッチはほとんどいつでも許されています。これは普通 Arch のツールが元のスクリプトに対して新しすぎて、うまく動かない場合に必要になります(libtool はよくパッチを当てられます)。
• *新しすぎる* コンパイラが原因のパッチは普通許されています。GCC リリースはより厳密になる傾向にあり、過去に許されていたものが許されなくなってきています。コンパイラエラーを修正してソースを Arch 上でビルドできるようにすることは一般的で容認できます。
• アプリケーションの *主要な機能* が動かないときは、バグフィックスのパッチが許されています。'主要な機能' を説明するために、DVD を書き込むアプリケーションについて考えてください。そのアプリケーションがバグにより DVD に書き込めないときは、主要な機能とみなされます。'ヘルプ' メニューが動かないときは、主要でない機能とみなされます。

パッチが推奨されない場合

• 主要でない機能の修正は私達の仕事ではなく、パッチはアプリケーションの機能に直接関係ないことを修正するために適用されるべきではありません。タイポや画像の修正のためのパッチは推奨されません。
• 追加の機能は Arch によって追加されるべき *ではありません*。完全に新しい機能を追加するパッチはアップストリームに送られるべきです。上で述べた通り、元の作者の 意図した通りにパッケージを提供します。我々の意図した通りではありません。
• アップストリームによって拒否された機能。パッチを送って元の開発者が拒否した場合、我々の思いに関係なくパッチを適用するべき *ではありません*。自由にアプリケーションをフォークして、そのアプリケーションにパッチを適用することができます。