Создание пакета Debian с нуля

[iSage]

>запуск make производит бинарный вызов hello и запускает двоичные выходы «Hello, World»
PROMPT approved.

[iSage]

Надо же, обидчивые какие. Банально вычитать перевод перед отправкой ума не хватило, зато на кнопочки тыкать много ума не надо.

[fshp]

Расстегните молнию. Бегите. Получайте удовольствие!
(Just unzip. Run. Enjoy!)

[amarao]

Ужасно. Просто ужасно. Очередной пересказ «подфигачить dh_make'ом». Ноль объяснений как оно работает и зачем.

[Sild]

А на каком уровень необходимо объяснять создание деб-пакета? Сам год назад какое-то время потратил на изучение вопроса по работе, остались неплохие заметки «для себя» — как по deb, так и по rpm. Думал, гайдов уже хватает. Но если сообществу всё мало — c удовольствием поделюсь.

[fshp]

На уровне "Имеем vim и ar"

[Sild]

К моему удивлению, с помощью ar собралось гораздо быстрее, чем через dpkg-build, как делалось раньше — при этом требуя минимум изменений. Поэтому спасибо за совет.

А про описание на этом уровне — почему бы и нет. Был бы спрос.

[fshp]

Спрос есть. Я на вас уже подписался.

[monah_tuk]

извиняюсь, но разве ar, это не архиватор, который, в основном, используют для сборки кучки объектников в статическую библиотеку?

[fshp]

А так же для сборки deb-пакета.

[monah_tuk]

А! Т.е. вы про формирование DEBIAN/* вручную со своими правилами отстройки кода и так далее, тогда понял. Делал, давно, но, пожалуй, тоже положу копеечку в копилку спроса.

[amarao]

Отлично, я рад, что хоть кто-то может про него рассказать подробно.

Дан код на питоне. Самописный, т.е. менять можно «под себя». Он предоставляет несколько модулей с main() внутри, т.е. может быть исполнен как программа. Нормальной практикой является использование setup.py с entry_points, которые задают console_script, который генерируется при установке пакета. setup.py использует stdeb, который настраивается pybuild'ом, который вызывается dh_python2(3) (с опцией --buildsystem=pybuild, который вызывается dpkg-buildpackage, который вызывается git-buildpackage, который вызывается build-and-provide скриптом debian-jenkins-glue, который вызывается jenkins'ом.

Задача: генерировать console_scripts не в /usr/bin, а в /usr/lib/other_app/plugins.

Как? Я эту проблему решил, причём довольно разумным терпимым методом (как мне кажется), но мне интересно было бы послушать других людей. Как сделать так, чтобы сгенерированный console_script после установки пакета был бы не в /usr/bin, а в /usr/lib/other_app/plugins? Желательно без костылей в виде «mv» где-то в потрошках, и без прямого перечисления всего и вся, т.е. «одной строчкой для всех console_scripts, которые генерирует setup.py». Они, если что, генерируются автоматически с помощью интроспекции модулей в коде setup.py.

[Sild]

Я плохо понимаю что происходит с питоном, в частности спефицику работы pybuild и dh_python. По религиозным соображениям мне приходится работать только с sh. Но в ближайшие пару дней найду время познакомиться поближе и попробую что-то подсказать.

[amarao]

Это касается практически любой другой системы. Адекватного метода сказать dh_install'у, что нужно не «copy», а «move» просто нет. Даже с использованием dh_exec'а.

[povetkon]

Тоже не понял, в чем смысл статьи

[savostin]

Пойду почитаю оригинал, может пойму хоть что-то.

[Sild]

Штойта, старый-добрый dpkg-build с {pre,post}inst и {pre,port}rm уже не в моде? Зачем мне ваш dh_make?

[amarao]

dh_make не собирает пакет, а создаёт debian-часть для пакета, т.е. генерирует скелет с прототипом rules. Речь не про бинарные пакеты (в которых есть набор скриптов), а про source-пакет, который пересобирается командой dpkg-buildpackage.

[Cryvage]

Объяснения получились на уровне «Открываем гримуар на странице 666 и зачитываем заклинание вслух, громко и четко». Или может это я такой тугой. Я так понял этот способ только для пакетов с исходниками. А куда копать если у меня есть исполняемый файл и «сошки», от которых он зависит? По сути нужно просто раскопировать это все по нужным системным папкам. Или не париться с пакетами и написать обычный скрипт? Хочется не просто сделать, чтобы работало, но и, по возможности, сделать так, как это принято.

[debsaw]

есть 2 типа зависимостей Depends и Build-Depends. Первые нужны для установки (ваш вариант), вторые для компиляции. И те и другие описываются при необходимости в файле debian/control. dh_make, про который говорилось в статье, создаст bolier plate для control файла. Его синтаксис описан тут:
https://www.debian.org/doc/debian-policy/ch-controlfields.html
То есть просто нужно дописать необходимые пакеты в правильные секции «заготовки» контрол файла.

[amarao]

«Как принято» для бинарного пакета сделать невозможно. Модель debian (и deb) подразумевает, что у вас есть исходный текст.

Если нет — попробуйте удовлетворить dh_install с помощью файла «имя пакета».install (в каталоге debian).

Т.е. кладёте дерево нужных файлов (т.е. usr/bin/foo, usr/lib/libfoo-1.so), делаете debian/control, а в debian/foo.install пишите usr/bin/foo\nusr/lib/libfoo-1.so.

debian/rules при этом выглядит так:

%:
dh $@


debian/changelog можно заполнить с помощью dch -i.

[19as]

А есть у кого инфа по созданию ярлыка (shortcut или desktop) на рабочем столе пользователя?
Интересует для deb пакета, чтобы ярлык был уже у существующих пользователей и у вновь регистрируемых (в скелетоне).
Как это правильно организовать...

[amarao]

Сам не пробовал, интуиция говорит, что dh-triggers, а так же http://sources.debian.net/src/dpkg/1.18.4/doc/triggers.txt/

[fshp]

уже у существующих пользователей и у вновь регистрируемых

Т.е. у всех? Тогда почему бы не положить его в /usr/share/applications?

[monah_tuk]

Вообще, когда система описаний (спеков) для сборки требует таких вот статей, что-то не так (у самого несколько PPA). Самые адекватные спеки, по функциональности и возможностями, имхо, у ArchLinux, AlpineLinux (они позаимствовали идеи у Arch, но спеки не на 100% одинаковые). Прямо подмывает сделать прокси-makepkg для deb-based систем, который будет брать спек в формате PKGCONFIG, генерировать инфраструктуру для dpkg-buildpackage и производить отстройку. Ну и возможность экспорта, что бы иметь возможность залить в тот же PPA.

Кстати, а никто не знает, вдруг подобное уже есть?

[fshp]

ArchLinux-пакеты не покрывают полностью функционал deb. reconfigure и update-alternatives как в Арче сделать?

[monah_tuk]

А не про сами пакеты и пакетную систему речь.

Данные действия вызываются из maintainer скриптов (аналоги самих скриптов — есть). Кроме того, они никакого отношения к описанию процесса сборки через control/rules/changelog не имеют. Я именно про это, про спек, а не про сам пакетный менеджер или формат пакета писал.

Т.е. что бы сделать описание сборки под Арч, достаточно одного файла, с простой шапкой, двумя функциями (build и install) и интуитивными командами (всё таки это шелл). А в debian:

• сделать "дебианизацию" пакета исходного кода
• распаковать исходники
• создать директорию debian с rules, control, changelog, format/version

Далее заполнить вышеозначенные файлы. А у каждого из них свой формат, со своим хитрым набором целей (rules) или специальными утилитами для обновления (changelog + dch). Если для примитивного опакечивания в арчике нужно минут 5-10 на создание правил, причём информации в "рыбе" файла хватает с избытком, то для debian — у меня меньше получаса не получается.

Добавить сюда невозможность (хотя фича спорная) при пакетировании автоматического версифицирования для пакетов сборке которых происходит из исходников из VCS; плюс то что сборку можно делать разными способами: debian/rules, dpkg-buildpackage, debuild, то в части описания сборки PKGBUILD и makepkg всё же удобнее.

Про подписи не говорю, оно сейчас и там и там есть в разном виде.

PS и да, я не пользователь Арча, лет несколько как.