Сборка deb-пакета с помощью debhelper (нестандартные системы сборки)

[Hephaestus]

Всем здрасьте.

Хочу собрать пакет для себя.
Однако для компиляции программы используется
не

Код: Выделить всё

configure && make && make install

а

Код: Выделить всё

configure && jam && jam install

debhelper по умолчанию не желает этого знать,
файл debian/rules заточен под make.
В результате компиляция даже не начинается.
Пакет создаётся, но почти пустой, там только /usr/share/doc
В итоге - не работает.

checkinstall, которому вроде бы всё равно, за кем следить
нормально воспринимает

Код: Выделить всё

checkinstall --install=no jam install

, проходит компиляция, инсталляция, но завершается с сообщением об ошибке сборки пакета по причине "не могу создать каталог".
Создавать каталог заранее руками не вариант.
Во-первых, это означает ручную работу вместо checkinstall (на кой он тогда нужен?), а во-вторых, каталогов там всё-таки гораздо больше одного.
В-третьих, с другими программами checkinstall справляется, всё создаётся как надо, а здесь - отлынивает. В итоге - не работает.

Ради интереса стянул source-RPM целевой программы, распаковал.
Подправил spec-файл, далее по команде

Код: Выделить всё

rpmbuild -ba speckfilename.spec

всё нормально скомпилировалось и создалось. Полученный rpm-файл успешно преобразовался в deb командой alien.
Так вот в spec-файле явным образом вызываются configure, jam, jam install, всё это снабжается переменными окружения, опциями и т.п. Т.е. это обычный скрипт, чем-то схожий с bash-скриптом.
rpmbuild создает временную директорию, куда складываются результаты компиляции, потом всё это собирается в пакет, в конце временные файлы удаляются.

debhelper (насколько я понял) работает схожим образом, тоже компилирует во временную директорию и потом собирает пакет, но разобраться в его работе значительно сложнее из-за большого количества dh_скриптов.

Я пробовал в файле rules явно указать использование jam (ну то есть примерно как в spec-файле rpm) не получилось. Что-то я сделал не так.
Официальное руководство на эту тему не очень распространяется, хотя там и указано, что системы сборки могут быть разными.

Можно извратиться и собрать rpm, который потом конвертировать в deb, но это обходной путь.
Меня же интересует правильный вариант.

Теперь, собственно, вопрос: Как правильно собирать deb-пакеты при условии нестандартной системы сборки (в частности jam)? Можно ли в файле rules явным образом указывать команду компиляции, опции, переменные окружения и т.п.?

[Bizdelnick]

Я пробовал в файле rules явно указать использование jam (ну то есть примерно как в spec-файле rpm) не получилось. Что-то я сделал не так.

Попробуйте как-нибудь исправить. (-:
Вообще это как раз и есть "правильный" вариант, если подходящего dh-скрипта нет. Равно как и в rpm при отсутствии подходящего макроса.

P. S. Случайно пробелы вместо табуляции не поставили?

[Hephaestus]

Ну что ж... Почти всё получилось.
Опишу, может кому пригодится.

Развернутое содержимое файла rules взято из официального руководства которое тут и добавлено к файлу rules, создаваемому dh_make
Использование DESTDIR при вызове jam install подсмотрено в spec-файле rpm.

Получилось вот что

Код:

#!/usr/bin/make -f # -*- makefile -*- # Sample debian/rules that uses debhelper. # This file was originally written by Joey Hess and Craig Small. # As a special exception, when this file is copied by dh-make into a # dh-make output file, you may use that output file without restriction. # This special exception was added by Craig Small in version 0.37 of dh-make. # Uncomment this to turn on verbose mode. #export DH_VERBOSE=1 %: dh $@ --with autotools-dev clean: dh_testdir dh_auto_clean dh_clean build: dh_testdir dh_auto_configure CC=/usr/bin/gcc-4.4 CXX=/usr/bin/g++-4.4 jam #здесь было dh_auto_build dh_auto_test binary: dh_testroot dh_prep dh_installdirs DESTDIR=./debian/имя_пакета jam install #здесь было dh_auto_install dh_install dh_installdocs dh_installchangelogs dh_installexamples dh_installman dh_installcatalogs dh_installcron dh_installdebconf dh_installemacsen dh_installifupdown dh_installinfo dh_installinit dh_installmenu dh_installmime dh_installmodules dh_installlogcheck dh_installlogrotate dh_installpam dh_installppp dh_installudev dh_installwm dh_installxfonts dh_bugfiles dh_lintian dh_gconf dh_icons dh_perl dh_usrlocal dh_link dh_compress dh_fixperms dh_strip dh_makeshlibs dh_shlibdeps dh_installdeb dh_gencontrol dh_md5sums dh_builddeb

Заменил вызов некоторых скриптов на вызов компилятора.
Какие именно скрипты выполняют make и make install, сказано в том же руководстве.
В получившемся файле меня немного смущает sha-bang.
Кроме того, в DESTDIR имя пакета приходится задавать явно, хотел сделать через переменные окружения, не осилил.
Здесь, наверно, можно многое выкинуть, но задача была в том, чтобы заменить dh_-скрипты на какие-то другие команды. Это удалось. В представленном виде всё работает.

Однако ощущается недостаток справочной информации по работе debhelper.
Тему можно закрыть.

[Bizdelnick]

У Вас вызывается много лишних скриптов в binary, впрочем они ничему не мешают.

В получившемся файле меня немного смущает sha-bang.

Почему? Всё нормально с ним.

ощущается недостаток справочной информации по работе debhelper.

Для всех скриптов есть man'ы, если что. В отличие от rpm'овских макросов и хелепров...

[Hephaestus]

У Вас вызывается много лишних скриптов в binary, впрочем они ничему не мешают.

Да, я говорил, что там можно много выкинуть.
Это просто как пример, что можно в файле rules вызывать всякие сторонние инструменты.
Развернутый вариант файла - для полноты картины.

Почему? Всё нормально с ним.

Ну, как Вам сказать...
Когда для сборки используется не make, а jam, а файл rules выглядит вот так

Код:

#!/usr/bin/make -f # -*- makefile -*- # Sample debian/rules that uses debhelper. # This file was originally written by Joey Hess and Craig Small. # As a special exception, when this file is copied by dh-make into a # dh-make output file, you may use that output file without restriction. # This special exception was added by Craig Small in version 0.37 of dh-make. # Uncomment this to turn on verbose mode. #export DH_VERBOSE=1 %: dh $@ --with autotools-dev

и при этом jam сама по себе позиционируется как замена make,
то откровенно говоря, был соблазн написать что-то вроде
#!/usr/bin/jam
То, что файл rules сам по себе является make-файлом как-то ускользает от внимания, особенно в его сокращённом виде.

Jam, кстати, не понравилась. Там всяких неявных вызовов ещё больше.
Я вообще не знаю, зачем она нужна. Чем их make не устраивает?

Для всех скриптов есть man'ы, если что. В отличие от rpm'овских макросов и хелепров...

Маны есть. И они даже не пустые.
Но всё-таки некоторые вещи там описаны недостаточно.
Вот у меня использована переменная DISTDIR. В манах она практически не упоминается.
Упоминается опция --destdir.
В руководстве есть пример для случая с make

Код: Выделить всё

make install \
  DESTDIR=/path/to/package_version-revision/debian/package

Я попытался по аналогии написать для jam

Код: Выделить всё

jam install DESTDIR=...

как Вы понимаете, не сработало.
Оказалось надо

Код: Выделить всё

DESTDIR=... jam install

но это в spec-файле я подглядел.
В документации к jam про DESTDIR я вообще ни слова не нашёл. Сработает или нет - чёрт его знает.
Возможно, что использование DESTDIR само собой разумеется, но это совсем не очевидно.
Или, скажем такая штука как $(MAKE). Тоже упоминается в манах, но где и как может использоваться - непонятно.
Вот в руководстве к debhelper не помешала бы какая-нибудь сводная таблица.
Мол, могут использоваться такие-то переменные окружения, означают они то-то и то-то, используются так-то и так-то. Но нету там такого. Вот поэтому и недостаток справочной информации. И умолчальный вид файла rules, на мой взгляд только усугубляет ситуацию.

[Bizdelnick]

откровенно говоря, был соблазн написать что-то вроде
#!/usr/bin/jam

Вы путаете систему сборки пакетов Debian, использующую make, с системой сборки программы, которая может использовать всё, что ей вздумается. То есть файл rules - это самый обычный мейкфайл, а в нём в правилах уже могут быть вызовы хоть make, хоть jam - всего, что разработчикам программы могло прийти в голову.

[Bizdelnick]

откровенно говоря, был соблазн написать что-то вроде
#!/usr/bin/jam

Вы путаете систему сборки пакетов Debian, использующую make, с системой сборки программы, которая может использовать всё, что ей вздумается. То есть файл rules - это самый обычный мейкфайл, а в нём в правилах уже могут быть вызовы хоть make, хоть jam - всего, что разработчикам программы могло прийти в голову.

Вот у меня использована переменная DISTDIR. В манах она практически не упоминается.
Упоминается опция --destdir.
В руководстве есть пример для случая с make

Код: Выделить всё

make install \
  DESTDIR=/path/to/package_version-revision/debian/package

Я попытался по аналогии написать для jam

Код: Выделить всё

jam install DESTDIR=...

как Вы понимаете, не сработало.
Оказалось надо

Код: Выделить всё

DESTDIR=... jam install

но это в spec-файле я подглядел.

DESTDIR - это переменная, специфичная для системы сборки. Даже не для make как таковой, а для autotools. В мейкфайле могло бы не быть ни одного упоминания этой переменной, тогда бы она никакого действия не оказывала.
Что касается двух форм записи, то они интерпретируются совершенно по-разному. В случае DESTDIR=/some/dir command оболочка устанавливает для вызова команды переменную окружения $DESTDIR, в случае же make DESTDIR=/some/path оболочка просто передаёт make аргумент, а уже make его парсит и устанавливает свою внутреннюю переменную. jam, по всей видимости, работает только с переменными окружения, или же для задания внутренних переменных надо использовать другой синтаксис (про jam не знаю, а например для cmake это бы выглядело как -DVARIABLE=value).

В документации к jam про DESTDIR я вообще ни слова не нашёл. Сработает или нет - чёрт его знает.
Возможно, что использование DESTDIR само собой разумеется, но это совсем не очевидно.

Полагаю, что в случае jam, как и в случае make, реакция на переменную $DESTDIR определяется правилами, определёнными в Jamfile, так что в документации jam вполне логично может ни слова об этом не быть. Надо смотреть документацию программы (файлы README и INSTALL, как правило), ну и в сам Jamfile заглядывать.

P. S. Мне тоже доводилось собирать пакеты, в которых использовался jam, правда только rpm. Сложилось впечатление, что выбирающие его разработчики вообще не думают о таких вещах, как пакеты, проверка зависимостей и прочая ерунда. Лишь бы у них самих кой-как собралось. Нормальные люди используют cmake или autotools, чуть менее нормальные - qmake или ещё какой scons, а люди, выбирающие jam, icmake и т. п., определённо имеют садистские наклонности.