Как мне обрабатывать отклонения патча после применения патчей с помощью 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
по-прежнему.