パッケージ中の推奨に従わねばなりません。登録する必要があります。大量のアーキテクチャ非依存データがプログラムと共にパッケージ化されるのは、良くあることではありません。音声ファイル、アイコン集、様々な模様の壁紙、その他一般的な画像ファイルです。このデータのサイズがパッケージの残りのサイズと比較して取るに足らないのであれば、おそらくは単一パッケージでひとまとめにしておくのがベストでしょう。ならなくても欲しいものが手に入ります。どのパッケージも依存していないものです。セクションからのみ検索を行います。正しい引数を渡せば、他の使われていないパッケージを捕らえようとします。バイトたりとも違わない、というものです。バージョンと開発元のバージョン間のすべての違いを簡単に比較するのにチェックサムを使えるようになります。作者と他の者は、あなたのパッケージを詳細に調査したい場合、ダウンロード時間を節約できます。中の最上位のディレクトリ名は問題にはされず、忘れられます。作者よ、恥を知りなさい!)。共にアップロードすべきですが、それが可能ではない場合が色々とあります。ない、あなたがアップロード前に削除しなければならない素材を含んでいる場合がこれにあたります。ファイルを自身で準備する必要があります。ネイティブパッケージとは違うことに注意してください。配布していたとしても再パッケージをしたくなるという場合がありえます。アーカイブから純粋に使われていないゴミを削除することで、非常に容量を節約できる時です。ここで慎重になって頂きたいのですが、ソースを再パッケージする場合は、決定を貫く用意をしてください。ソースパッケージの由来をドキュメントにすべきです。ターゲットを追加するのも良い考えです。開発元の作者由来ではないファイルや、あなたが内容を変更したファイルを含めるべきではありません。[2]法的理由から不可能であるものを除いて、開発元の作者が提供しているビルドおよび移植作業環境を完全に保全すべきです。ビルドにしか使われないから、というのは十分な理由にはなりません。省略すべきではありません。スクリプトを実行してそれを上書きすることであったとしても、です。ミラーからソースを取得する、というのは普通です)。works.デバッグパッケージは、そのパッケージがデバッグシンボルを提供するパッケージに依存する必要があり、この依存関係はバージョン指定が必要であるということに注意してください。メタパッケージのベストプラクティス¶メタパッケージは、時間がかかる一貫したセットのパッケージをインストールするのを楽にしてくれる、ほぼ空のパッケージです。そのセットの全パッケージに依存することで、これを実現しています。力のおかげで、メタパッケージのメンテナは依存関係を調整すればユーザのシステムが自動的に追加パッケージを得ることができます。よって自動的に削除もされます)。