Как мне обрабатывать отклонения патча после применения патчей с обновлением?
Я использовал uupdate для обновления исходного пакета с 0.7.0 до 0.7.3. Он делает это обновление с исправлениями, и у меня было несколько отклонений исправлений. Я не уверен, что делать дальше. Должен ли я:
- редактировать старый пакет исходного кода (0.7.0), а затем повторно запускать uupdate?
- редактировать новый пакет исходного кода (0.7.3), а затем повторно запускать uupdate?
- редактировать файлы .rej напрямую?
- использовать такой инструмент, как kdiff3?
- попробовать что-то еще?
На данный момент Я думаю, что ответ заключается в том, чтобы использовать инструмент, более близкий к тому, с чем я знаком (исходя из фона слияния черепах и слитков).
Я искал все выше и ниже, как люди управляют отклонениями патчей, и мне не повезло, поэтому я с радостью переведу RTFM, если вы сможете предоставить ссылку на FM, если он существует .
2 ответа
Я согласен с @maco на ручное разрешение конфликта. Видя опции, которые вы даете, вам, вероятно, нужно по-настоящему понять, что uupdate does, а именно:
- извлекать новый tarball из родительского каталога;
- попытаться применить предыдущий diff .gz (если вы не используете стиль v3 (quilt)) в новый каталог.
Отклонение патча происходит от применения этого diff.gz к новому каталогу.
Теперь перейдем к вашим опциям:
- отредактируйте старый пакет с исходным кодом => вы не должны изменять старый пакет с исходным кодом для создания нового ; [ 1110]
- отредактируйте новый пакет с исходным кодом и перезапустите uupdate => , в этом нет никакого смысла, так как патч не может быть применен к новому источнику, и вы не должны изменять исходный источник (кроме с исправлениями, которые можно найти в diff.gz) ;
- отредактируйте файлы .rej => . Здесь находятся файлы .rej, чтобы показать вам, что не удалось применить; редактирование их не решит вашу проблему, но вы должны взглянуть на них, чтобы увидеть, нужно ли применять неудачные изменения ;
- использовать инструмент diff => , конечно, это может быть хорошая идея, (
vim -dваш друг), хотя файлы .rej уже должны дать вам представление о том, что не удалось применить. Вы также можете прочитать предыдущий diff.gz, чтобы понять, какие файлы он изменял.
Как правило, большинство конфликтов обновлений, с которыми я встречался, были связаны с плохой упаковкой в предыдущей версии пакета, а именно с diff.gz, который изменил исходный код, а не просто добавил каталог debian /. Это легко проверить:
zcat ../yourpackagename_0.7.0-1.diff.gz | diffstat
предоставит вам список файлов, измененных предыдущим патчем (адаптируйте имя файла к вашим потребностям). Если вы найдете файлы, которых нет в каталоге debian / в этом списке, то ваша проблема наверняка есть. В этом случае проверьте, что было изменено:
- В большинстве случаев происходит сбой автоинструмента при вызове
debuild -S: один из сценариев autoconf / automake был изменен, и эта модификация не будет применить больше. Обычно безопасно отбросить это изменение в новой версии; - В некоторых других случаях исходный код был исправлен вручную (без использования dpatch / simple-patchsys / quilt / что-либо еще). В этом случае проверьте, следует ли применять исправление к новой версии (см., Например, журнал изменений). Если это так, то сделайте чистый патч, используя соответствующий менеджер патчей. Будущие упаковщики будут вам благодарны: -)
Я бы просто вручную разрешил конфликты и запустил debuild -S как обычно.