Re: dh and make

[Artem Chuprina <ran@ran.pp.ru>]

Maxim Nikulin -> debian-russian@lists.debian.org  @ Sun, 02 Jun 2013 12:15:44 +0700:

 MN> Приветствую.

 MN> Что-то я запутался с debhelper.

 MN> Файл debian/rules при сборке пакета - это Makefile. Идея make в том, чтобы по
 MN> набору правил сделать все что нужно, но не делать лишней работы. Время от
 MN> времени требуется что-нибудь подшаманить в каком-нибудь пакете, но с первого
 MN> раза иногда ошибаешься, и пакет собирается неправильно. Обычно можно было
 MN> подправить файлы и запустить компиляцию и сборку пакета без clean. В
 MN> результате успешно собирался новый пакет. При этом заново компилировалось
 MN> только то, что было изменено, и это существенно экономило время. В самом
 MN> конце, когда все начинало работать, можно было пересобрать пакет начисто.

 MN> Сейчас рекомендуют писать debian/rules вида
 MN> %:
 MN> 	dh $@
 MN> с некоторыми override. Естественно, зависимости между целями при этом
 MN> теряются. Как я понял, dh знает, в каком порядке надо запускать dh_ скрипты, и
 MN> сохраняет успешно закончившиеся команды в *.debhelper.log. Когда запускаешь
 MN> его второй раз, то он не обращает внимания, какие файлы изменились, и просто
 MN> начинает с команды, которую не нашел в .log файле. Если один раз пакет
 MN> собрался, то второй раз dh вообще ничего не будет делать, пока не вызовешь
 MN> соответствующий clean.

 MN> Есть надежда, что я пропустил, что-то очень простое и важное.

 MN> Есть ли штатный способ попросить dh пересобрать изменившиеся исходники и
 MN> сделать новые .deb файлы, если сборка пакетов уже делалась и закончилась
 MN> успешно? Чтобы не ждать, пока выполнится сборка с нуля.

 MN> Редактировать руками debhelper.log как-то неинтересно.

 MN> -- 
 MN> Максим Никулин

 MN> P.S. В hello-debhelper цели и зависимости задаются руками, компиляция прибита
 MN> к configure с помощью файлика build. Скрипт dh вообще не используется.

Видимо, новая мода.  К сожалению, надо сказать, что в прошлом там бывали
серьезные проблемы - многие пакеты не были рассчитаны на запуск сборки
не с нуля, мне приходилось ходить по этим граблям.  В том числе и по
граблям вида "если запустить не с нуля, а с промежуточного отвала, то
собраться-то пакет соберется, но результат будет существенно отличаться
от сборки с нуля".  Правда, уже не помню, в каком пакете была такая
грабля.