DeveloperWiki:パッチ

パッチ

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

バニラパッケージ

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

パッチが許される場合

It's inevitable that some software will need modifications to work.

• Patches to the *build system* are pretty much always allowed. This is usually needed when Arch's tools are too new for shipped scripts, and things do not work right (libtool is a known offender here).

• Patches due to a *too new* compiler are usually allowed. GCC releases tend to be more and more strict, disallowing things that were once allowed. Fixing compiler errors so that the source builds under Arch are common and allowable.

• When a *major feature* doesn't work in the app, bug fix patches are allowed. To explain 'major feature', think of an app that burns DVDs - if it doesn't burn DVDs due to a bug, well, that's a major feature. If the 'Help' menu doesn't work, well, that's a minor feature.

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

• Fixing minor features is not our job and patches should not be applied to fix things not directly related to the app's functionality. Patches to fix typos or images are discouraged.

• Additional features should *NOT* be added by Arch. Patches that add completely new features should be sent to upstream. As said before - we ship packages as the ORIGINAL AUTHORS intended them. Not as WE intend them.

• Features denied by upstream. If a patch was sent and the original developers denied it, we should *NEVER* apply that patch, no matter how opinionated we are. You are welcome to fork the app and supply a package for your own app.