開発者へのベストプラクティスをいくつか提供します。すべての勧めは単に勧めであり、要求事項やポリシーではありません。開発者らからの主観的なヒント、アドバイス、ポインタです。あなたにとって一番うまくいくやり方を、どうぞご自由に選んでください。ヘルパースクリプトを使う根拠は、多くのパッケージ間でメンテナらに共通のロジックを利用・共有させるようになるからです。置き、メンテナスクリプトにメニューエントリを登録・解除するためのコマンドを追加する必要があります。これはパッケージが行う、非常に一般的なことです。メニューディレクトリが変更された場合、すべてのパッケージを変更する必要があります。ヘルパースクリプトがこれらの問題を引き受けてくれます。ヘルパースクリプトの期待するやり方に従っているならば、ヘルパースクリプトはすべての詳細について考慮をします。パッケージを新しいバージョンのヘルパースクリプトでリビルドする必要があるだけです。他に何の変更も必要ありません。複数の異なったヘルパーが含まれています。使えそうなヘルパーの一部を取り出して選ぶことはできず、何を行うにもヘルパーを使う必要がありました。ファイルをインストールするなどします。内で使える部分では小さなヘルパースクリプトを使い、手製のコマンドを使うといった十分な柔軟性を与えてくれます。使い始めることができます。debhelper化されたパッケージに変換するのに利用できます。ヘルパーをわざわざ理解する必要がないので、満足できないでしょう。ヘルパースクリプトを使おうとするのであれば、そのヘルパーを使うこと、つまり前提と動作を学ぶのに時間を割く必要があります。巨大で複雑なパッケージには、対処が必要なたくさんのバグが含まれているかもしれません。直接ソース中で大量のバグを修正し、あまり注意を払っていなかった場合、適用した様々なパッチを識別するのは難しいことになるでしょう。幾つか修正を取り入れた新しい開発元のバージョンへパッケージを更新する必要が出た場合、とても悲惨なことになります。すべて適用することもできませんし、開発元で修正されたバグごとにどのパッチをバックアウトするようにすればよいのか分かりません。ディレクトリ内にあります。ルールへの依存を通じて適用されることだけです。information.他にもパッチを管理するツールはあります。簡単に扱うことができます。ビルドディレクトリからパッケージの一時ツリーへ、適切なファイルを移動する必要があるだけです。内で正しく設定したのを忘れずに確認してください。ファイルに関するものです。パッケージ説明文についてのポリシーを補完します。ファイルの対応するフィールドにて定義されている様に、パッケージの概要とパッケージに関する長い説明文の両方を含んでいます。パッケージ説明文の双方の部分についての一般的なガイドラインが記述されています。特化したガイドラインを含んでいます。パッケージ説明文の基本的なガイドライン¶パッケージの説明文は平均的なユーザーに向けて書く必要があります。平均的な人というのは、パッケージを使って得をするであろう人のことです。開発用パッケージであれば開発者向けですし、彼ら向けの言葉でテクニカルに記述することができます。汎用的なアプリケーション、例えばエディタなどであれば、あまり技術的ではないユーザ向けに書く必要があります。パッケージ説明文のレビューを行った結果、ほとんどのものがテクニカルである、つまり、技術に詳しくはないユーザに通じるようには書かれてはいないという結論に達しました。あなたのパッケージが、本当に技術に精通したユーザ用のみではない限り、これは問題です。ジャーゴンを避けましょう。知識がないと仮定してみましょう。技術用語を使わねばならない場合は、説明しましょう。客観的になりましょう。パッケージ説明文はあなたのパッケージの宣伝場所ではありません。あなたがそのパッケージをどんなに愛しているかは関係ありません。その説明文を読む人は、あなたが気にすることと同じことを気にはしないであろうことを覚えておいてください。名前を参照する場合には、もしあれば正規名称を使いましょう。