ドキュメントパッチの適用
私たちのユースケースの XNUMX つでは、 ピリット ソース パッケージを作成し、上流の git リポジトリで見つかったパッチを適用したいと考えています。 これは一般的な操作であり、常に単純である必要があります。 残念ながら、パッチは、ソース パッケージの形式と、使用中の Git パッケージ化ワークフロー (Git を使用してパッケージを保守する場合) に応じて、さまざまな方法で処理される可能性があります。
解凍されたソースパッケージの場合 あなたは走りました 適切なソース pyrit そしてあなたは ピリット-0。
4.0 ディレクトリ。 patch -p1 を使用してパッチを直接適用できます。 パッチファイル:
$ 適切なソース pyrit
[...]
$ cd pyrit-0.4.0
$ wget https://github.com/JPaulMora/Pyrit/commit/14
➥ ec997174b8e8fd20d22b6a97c57e19633f12a0.patch -O /tmp/pyrit-patch
[...]
$ パッチ -p1
パッチファイル cpyrit/pckttools.py
$ 適切なソース pyrit
[...]
$ cd pyrit-0.4.0
$ wget https://github.com/JPaulMora/Pyrit/commit/14
➥ ec997174b8e8fd20d22b6a97c57e19633f12a0.patch -O /tmp/pyrit-patch
[...]
$ パッチ -p1
パッチファイル cpyrit/pckttools.py
ハンク #1 は 53 (オフセット -1 ライン) で成功しました。
$ dch --local buxy 「scapy 2.3 で動作するようにパッチを適用します」
ハンク #1 は 53 (オフセット -1 ライン) で成功しました。
$ dch --local buxy 「scapy 2.3 で動作するようにパッチを適用します」
この時点で、ソース コードに手動でパッチを適用しており、変更したバージョンのバイナリ パッケージをすでにビルドできます (セクションを参照) 9.1.4、「 建設」[231ページ])。 しかし、更新されたソース パッケージをビルドしようとすると、「予期しないアップストリームの変更」を理由に失敗します。 これは、pyrit (大部分のソース パッケージと同様) がソース形式を使用しているためです (「 debian/ソース/フォーマット ファイル) 3.0 (キルト) として知られており、アップストリーム コードへの変更は、 debian/パッチ/ そしてどこ debian/パッチ/シリーズ ファイルは、パッチを適用する必要がある順序を示します。 次のコマンドを実行すると、変更を新しいパッチに登録できます。 dpkg-source --commit:
$ dpkg-source --commit
dpkg-source: info: ローカルの変更が検出されました。変更されたファイルは次のとおりです: pyrit-0.4.0/cpyrit/pckttools.py
希望のパッチ名を入力します: scapy-2.3.patch の修正
dpkg-source: info: ローカルの変更が新しいパッチに記録されました: pyrit-0.4.0/debian/
➥ patches/fix-for-scapy-2.3.patch
$ tail -n 1 debian/パッチ/シリーズ
scapy-2.3.patch の修正
$ dpkg-source --commit
dpkg-source: info: ローカルの変更が検出されました。変更されたファイルは次のとおりです: pyrit-0.4.0/cpyrit/pckttools.py
希望のパッチ名を入力します: scapy-2.3.patch の修正
dpkg-source: info: ローカルの変更が新しいパッチに記録されました: pyrit-0.4.0/debian/
➥ patches/fix-for-scapy-2.3.patch
$ tail -n 1 debian/パッチ/シリーズ
scapy-2.3.patch の修正
キルトパッチシリーズ このパッチ管理規則は、という名前のツールによって普及しました。 キルト したがって、「3.0 (quilt)」ソース パッケージ形式はこのツールと互換性がありますが、使用する形式に多少の違いはあります。 debian /パッチ パッチ。 このツールは同じ名前のパッケージで入手でき、ここで素晴らしいチュートリアルを見つけることができます。
➨ https://raphaelhertzog.com/2012/08/08/
debian パッケージでキルトを使用してパッチを管理する方法/
キルトパッチシリーズ このパッチ管理規則は、という名前のツールによって普及しました。 キルト したがって、「3.0 (quilt)」ソース パッケージ形式はこのツールと互換性がありますが、使用する形式に多少の違いはあります。 debian /パッチ パッチ。 このツールは同じ名前のパッケージで入手でき、ここで素晴らしいチュートリアルを見つけることができます。
➨ https://raphaelhertzog.com/2012/08/08/
debian パッケージでキルトを使用してパッチを管理する方法/
ソース パッケージが 1.0 または 3.0 (ネイティブ) ソース形式を使用している場合、アップストリームの変更をパッチに登録する必要はありません。 これらは、生成されるソース パッケージに自動的にバンドルされます。
Git リポジトリを使用する場合 Git を使用してソース パッケージを取得した場合、状況はさらに複雑になります。 複数の Git ワークフローと関連ツールがあり、すべての Debian パッケージが同じワークフローとツールを使用しているわけではないことは明らかです。 ソース形式についてすでに説明した区別は依然として重要ですが、パッチがソース ツリーに事前に適用されているかどうか、またはパッチがソース ツリーにのみ保存されているかどうかも確認する必要があります。 debian /パッチ (この場合、それらはビルド時に適用されます)。
最も人気のあるツールは git-buildpackage。 これは、git-lab.com/kalilinux/packages 上のすべてのリポジトリを管理するために使用されます。 これを使用すると、パッチはソース ツリーに事前に適用されませんが、 debian /パッチ。 そのディレクトリにパッチを手動で追加し、リストすることができます。
in debian/パッチ/シリーズ ただし、git-buildpackage のユーザーは次のことを使用する傾向があります。 ポンド pq パッチ シリーズ全体を XNUMX つのブランチとして編集し、好みに応じて拡張またはリベースできます。 チェック gbp-pq(1) それを呼び出す方法を学びます。
git-dpm (同じ名前の関連コマンドを含む) は、現在使用されているもう XNUMX つの git パッケージング ツールです。 メタデータを記録します debian/.git-dpm そして、コンテンツから構築される継続的にリベースされるブランチをマージすることで、ソース ツリーに適用されたパッチを維持します。 debian /パッチ.