Как мне обрабатывать отклонения патча после применения патчей с помощью uupdate?

Я использовал uupdate для обновления исходного пакета с 0.7.0 до 0.7.3. Он делает это обновление с исправлениями, и у меня было несколько отклонений исправлений. Я не уверен, что делать дальше. Должен ли я:

  • отредактировать старый пакет с исходным кодом (0.7.0), а затем повторно запустить uupdate?
  • отредактировать новый пакет с исходным кодом (0.7.3), а затем повторно запустить uupdate?
  • редактировать файлы.rej напрямую?
  • использовать такой инструмент, как kdiff3?
  • попробовать что-нибудь еще?

На данный момент, я думаю, что ответ заключается в том, чтобы использовать инструмент, более близкий к тому, с чем я знаком (исходя из фона слияния черепахи и прозрачного слияния).

Я искал высоко и низко, как люди управляют отклонениями патчей, и мне не повезло, поэтому я с радостью переведу RTFM, если вы сможете предоставить ссылку на FM, если таковой существует.

2 ответа

Решение

Я согласен с @maco на ручное разрешение конфликта. Видя варианты, которые вы даете, вы, вероятно, должны действительно понимать, что uupdate does, который:

  • распаковать новый архив в родительский каталог;
  • попробуйте применить предыдущий diff.gz (если вы не используете стиль v3 (quilt)) к новому каталогу.

Отклонения патча происходят от применения этого diff.gz к новому каталогу.

Теперь, чтобы просмотреть ваши варианты:

  • отредактируйте старый пакет с исходным кодом => вы не должны изменять старый пакет с исходным кодом, чтобы создать новый;
  • отредактируйте новый пакет с исходным кодом и перезапустите uupdate => в этом нет никакого смысла, потому что патч не может быть применен к новому источнику, и вы не должны изменять исходный источник (за исключением патчей, которые находятся в diff.gz);
  • отредактируйте файлы.rej => здесь находятся файлы.rej, чтобы показать вам, что не удалось применить; редактирование их не решит вашу проблему, но вы должны взглянуть на них, чтобы увидеть, нужно ли применить неудачные изменения;
  • используйте diff tool => конечно, это может быть хорошей идеей, ( vim -d Ваш друг), хотя файлы.rej уже должны дать вам представление о том, что не удалось применить. Вы также можете прочитать предыдущий diff.gz, чтобы понять, какие файлы он изменял.

Как правило, большинство конфликтов uupdate, с которыми я столкнулся, были связаны с плохой упаковкой в ​​предыдущей версии пакета, а именно с diff.gz, который изменил исходный код, а не просто добавил каталог debian /. Это можно легко проверить:

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

предоставит вам список файлов, измененных предыдущим патчем (адаптируйте имя файла к вашим потребностям). Если вы найдете файлы, которых нет в каталоге debian / в этом списке, то ваша проблема наверняка есть. В этом случае проверьте, что было изменено:

  • В большинстве случаев это беспорядок автоинструментов, когда debuild -S был вызван: один из сценариев autoconf / automake был изменен, и это изменение больше не будет применяться. Обычно безопасно отбросить это изменение в новой версии;
  • В некоторых других случаях исходный код был исправлен вручную (без использования dpatch/simple-patchsys/quilt/ что-либо еще). В этом случае проверьте, следует ли применять исправление к новой версии (см., Например, журнал изменений). Если это так, то сделайте чистый патч, используя соответствующий менеджер патчей. Будущие упаковщики будут вам благодарны за это:-)

Я бы просто вручную разрешил конфликты и запустил debuild -S по-прежнему.

Другие вопросы по тегам