web-dev-qa-db-ja.com

更新プログラムでパッチを適用した後、パッチ拒否を処理するにはどうすればよいですか?

Uupdateを使用して、ソースパッケージを0.7.0から0.7.3に更新しました。パッチを使用してこの更新を行いますが、いくつかのパッチが拒否されました。次に何をすべきかわからない。私は:

  • 古いソースパッケージ(0.7.0)を編集してから、uupdateを再実行しますか?
  • 新しいソースパッケージ(0.7.3)を編集してから、uupdateを再実行しますか?
  • .rejファイルを直接編集しますか?
  • kdiff3などのツールを使用しますか?
  • 他に試してみてください?

この時点で、答えは、私がよく知っているものに沿ったツールを使用することだと考えています(亀のマージとクリアケースのマージの背景から)。

パッチの拒否を管理する方法について高低を検索しましたが、運がありませんでしたので、FMへのリンクを提供できる場合は喜んでRTFM

4
mfisch

競合を手動で解決することに@macoに同意します。あなたが与えるオプションを見て、おそらくあなたは本当に_uupdate does、つまり:

  • 親ディレクトリで新しいtarballを抽出します。
  • 以前のdiff.gzを(v3(キルト)スタイルを使用していない限り)新しいディレクトリに適用してみてください。

パッチが拒否されるのは、このdiff.gzを新しいディレクトリに適用したためです。

次に、オプションを確認します。

  • 古いソースパッケージを編集=> 新しいソースパッケージを作成するために古いソースパッケージを変更しないでください;
  • 新しいソースパッケージを編集し、uupdate => 再パッチを新しいソースに適用できず、元のソースを変更しないでください(パッチを除き、 diff.gz)にあります;
  • .rejファイルの編集=> 。rejファイルは、適用に失敗したものを示すためにここにあります;それらを編集しても問題は修正されませんが、失敗した変更が必要であるかどうかを確認する必要があります適用済み;
  • diffツールを使用=> 確かに、それは良い考えかもしれません、(vim -dはあなたの友人です。ただし、.rejファイルは、何が適用に失敗したかを既に示しているはずです。また、以前のdiff.gzを読んで、どのファイルが変更されていたかを把握することもできます。

一般に、私が出会ったuupdateの競合のほとんどは、以前のバージョンのパッケージの不適切なパッケージング、つまりdebian /ディレクトリを追加する代わりにソースを変更したdiff.gzによるものでした。これは簡単に確認できます。

zcat ../yourpackagename_0.7.0-1.diff.gz | diffstat

前のパッチで変更されたファイルのリストが表示されます(ファイル名をニーズに合わせて調整します)。このリストのdebian /ディレクトリにないファイルを見つけた場合、問題はおそらくそこにあります。この場合、変更内容を確認してください。

  • ほとんどの場合、debuild -Sが呼び出されました:autoconf/automakeスクリプトの1つが変更され、この変更はもう適用されません。通常、この変更を新しいバージョンにドロップしても安全です。
  • 他の場合には、ソースコードに手動でパッチが適用されています(dpatch/simple-patchsys/quilt/whateverを使用せずに)。この場合、パッチを新しいバージョンに適用する必要があるかどうかを確認します(たとえば、変更ログを読みます)。存在する場合は、適切なパッチマネージャーを使用してクリーンパッチを作成します。将来のパッケージャーはそのことに感謝します:-)
3
ℝaphink

手動で競合を解決し、debuild -S いつものように。

2
maco