masai 05.11.2009 22:28
How-to`s — Как сделать deb-пакет со своими скриптами
Рано или поздно у продвинутого пользователя линукса накапливается набор собственных скриптов, хранящихся где-то в «~/bin». Но каталог с программами не так красиво смотрится в домашнем каталоге, да и потом если делиться с друзьями, то приходится отправлять в архиве, говорить куда что копировать, убеждать их, что загромождение домашнего каталога — неизбежное зло. Можно, конечно и куда-то в «/usr/local/bin» их поместить, но можно потратить десять минут и собрать пакет, который потом легко устанавливается (и удаляется) штатными средствами. Причём туда, куда надо.Посмотрим, как это делается.
В качестве примера скриптов возьмем, например следующие два.
Первый загружает цитаты с lorquotes.ru.
1 |
#!/bin/sh
|
А второй — выводит и при помощи утилиты fortune.
1 |
|
Сохраним их в отдельный каталог, который при сборке пакета должен иметь имя вида «пакет-версия». В нашем случае это будет «lorquotes-0.1».
Теперь создадим заготовку пакета при помощи команды dh_make (есть в репозитории под именем — сюрприз! — «dh-make»). Для этого в нашем каталоге выполним следующую команду:
dh_make --createorig -c gpl3 -e [email protected] -i -p lorquotes_0.1Довольно длинно, не так ли? Разберём по порядку:
--createorig — создать отдельную папку с исходниками, это будет нужно при создании пакета;
-c gpl3 — указать в качестве лицензии GPL3 (какие ещё есть лицензии ,можно посмотреть в man-страничке утилиты dh_make);
-e [email protected] — электронная почта собравшего пакет (то есть ваш);
-i — говорим, что пакет не зависит от платформы (bash-скрипты везде одинаковы ведь);
-p lorquotes_0.1 — указываем имя пакета (вообще, необязательно).
Утилита спросит, всё ли она правильно поняла, на что мы честно соглашаемся и заходим в папку.
Как видим, старое содержимое скопировалось в каталог «lorquotes-0.1.orig» (спасибо опции --createorig), а в «lorquotes-0.1» появился каталог «debian» с кучей файликов непонятного назначения. Собственно, содержимое этого каталога и определяет как будет вести себя пакет при установке и что он будет содержать.
Но сперва нужно создать мейкфайл. Это специальный файл, имеющий имя Makefile и говорящий сборщику пакета, как скомпилировать исходнуе тексты и куда устанавливать его содержимое. Структура нашего мейкфайла очень проста:
DESTDIR =Заметьте, что некоторые строки набраны с отступом при помощи табуляции. Именно так и нужно набирать. Это важно!
BIN = $(DESTDIR)/usr/bin
build:
true
install:
install -d $(BIN)
install -m755 lor $(BIN)
install -m755 lor-update $(BIN)
Мейкфайл — это просто предписание команде «make» выполнить определенный набор действий.
В строке 1 определены специальные переменные: DESTDIR — каталог, в который будет устанавливаться наш пакет. Эта переменная обязательно должна быть в мейкфайле, так как черех неё потом сборщик пакета указывает каталог назначения.
В строке 2 указан каталог, куда будут установлены наши скрипты. Без этой переменной уже можно было обойтись, так как она пользовательская и введена для удобства.
Строка с «build» — это одна из целей, которых должен достичь make. После двоеточия можно было указать список целей, от которых цель «build» зависит, но у нас и компилировать-то нечего, потому ничего и не указано. После цели идут команды (внимание, с отступом!), которые необходимо выполнить для достижения этой цели. Так как ничего выполнять не надо, то там стоит команда true, которая ничего не делает (такая у неё работа).
Аналогично описана цель «install». Но тут уже нужны действия: а именно создание каталога назначения и копирование в него с соответствующими правами наших скриптов. Вместо обычных команд создания и копирования используется утилита install, которая более интеллектуальна и специально для этих целей предназначена.
Итак, создаем в папке со скриптами (не в debian) мейкфайл под именем Makefile. Теперь мы можем при помощи команд «make» (ничего не делает, т.к выполнится первая цель в файле, т.е. «build») и «sudo make install» (копирует скрипты куда надо) собрать и установить вручную наши скрипты. Но вручную нам не нужно, мы ведь пакет хотим собрать. Поэтому переходим к следующему этапу.
Настроим свойства нашего пакета. Перейдём в каталог «debian» и откроем файл «control». Он содержит информацию о пакете, его зависимостях и так далее. Заполним его как анкету.
Source — название того, что мы сейчас собираем,
Section — в какую секцию дерева репозитория поместить наш пакет,
Priority — важность пакета,
Maintainer — сборщик,
Build-Depends — какие программы нужны для сборки пакета,
Standards-Version — версия стандарта, описывающего сборку пакетов,
Homepage — домашняя страничка (если есть),
Package — имя собственно deb-пакета,
Architecture — архитектура, под которую он собирается (i386, amd64 и иже с ними),
Depends — от каких пакетом наш зависит,
Description — описание, короткое в той же строке и длинное ниже (обратите внимание на пробел в начале строки с длинным описанием).
Я для примера сделал такой файл:
Source: lorquotesДумаю, указывать в зависимостях шелл и libc6 смысла нет. Они точно есть в любой системе (или нет?).
Section: misc
Priority: optional
Maintainer: Vasiliy Pupkin
Build-Depends: debhelper (>= 7)
Standards-Version: 3.8.3
Homepage: http://pupkin.example.com/lorquotes/
Package: lorquotes
Architecture: all
Depends: wget, fortune-mod
Description: Small LOR quotes utility
Shows you random quote from lorquotes.ru.
Теперь подправим файл «changelog». Он содержит историю версия нашего пакета. Во время правки не забывайте, что он тоже имеет строгий формат и не добавляйте лишние отступы и строки.
Вот мой вариант:
lorquotes (0.1-1) unstable; urgency=lowunstable — это имя ветки дистрибутива, для которой готовится пакет, а urgency — это приоритет.
* Initial release
-- Vasiliy Pupkin Thu, 05 Nov 2009 19:53:58 +0200
В том же каталоге есть файл «rules». Это обычный мекфайл, который и отвечает за конфигурирование и сборку пакета. Но так как мы ничего экстраординарного не делали, оставим всё как есть.
В файле «copyright» находится лицензия. Мы лицензию сразу указали, так что и этот файл трогать не будем.
Итак, остались ещё следующие важные для нас файлы.
«cron.d.ex». Переименовываем его в «cron.d». Он содержит информацию о регулярных действиях, которые будет выполнять установленная программа. В нашем случае — ежедневное обновление базы цитат в полдень:
#
# Regular cron jobs for the lorquotes package
#
0 12 * * * root < -x /usr/bin/lor-update > && /usr/bin/lor-update
«postrm.ez». Переименовываем в «postrm». Это скрипт, запускаемый после удаления пакета. Заставим его очищать нашу базу цитат, хранящуюся в «~/.lor». Хотя хранить базу в домашнем каталоге не совсем верно идеологически. Но, думаю, после этого поста читатель и сам исправит эту неточность. Итак, мой «postrm»:
#!/bin/shОстальные файлы нам не нужны и смело их удаляем. Это разные заготовки. Например, для man-страниц.
# postrm script for lorquotes
#
# see: dh_installdeb(1)
set -e
case "$1" in
purge|remove|upgrade|failed-upgrade|abort-install|abort-upgrade|disappear)
rm -rf ~/.lor
;;
*)
echo "postrm called with unknown argument \`$1'" >&2
exit 1
;;
esac
# dh_installdeb will replace this with shell code automatically
# generated by other debhelper scripts.
#DEBHELPER#
exit 0
Переходим теперь в каталог со скриптами (т.е. на уровень выше) и даём команду на сбору пакета:
debuildОна собирает пакет, проверяет на ошибки, а потом пробует его подписать вашим GPG-ключом. Но даже если ей подписать не удастся, пакет будет собран. Найти его можно будет в каталоге уровнем выше. Там же будет архив с исходниками и вспомогательные файлы, нужные, если вы хотите создать свой репозиторий или загрузить пакет в уже существующий.
Конечно, при сборке пакета будут предупреждения. Но мы ведь не закачивать его в дебиановский репозиторий будем, а для себя собираем. Так что устранение причин предупреждений остаётся в качестве домашнего задания читателю. (Кстати, это несложно.)
Вот и всё! Осталось только установить пакет. :)
Как видите, ничего сложного. Еслиинтересуют подробности или захотелось собрать пакет позаковыристее, милости просим на соответствующую страничку дебиановской документации.
А вот архив с исходниками и пакетом: lorquotes_0.1.zip
lwilis 05.11.2009 23:08 #
+ 0 -
хоть я и слакварщик, но труд автора оцениваю как очень достойный.
Спасибо! Идея интересная - пару раз проскакивали мысли вроде "как такие скрипты организовать, что б обновлять удобно, да и не терялись бы" :)
Кстати, способ подходит для любого пакетного дистрибутива - только реализация различается.
Кстати, способ подходит для любого пакетного дистрибутива - только реализация различается.
Отличная статья! Побольше бы таких.
Несколько замечаний:
Имхо, ещё как имеет. К тому же, lor-update требует wget (довольно стандартная утилита, но всё же), а lor — fortune.
После debuild можно точку не ставить — она переносится на начало нового абзаца, что выглядит довольно некрасиво.
Ещё раз спасибо за статью!
Несколько замечаний:
поторая ничего не делает
Думаю, указывать в зависимостях шелл и libc6 смысла нет. Они точно есть в любой системе (или нет?).
Имхо, ещё как имеет. К тому же, lor-update требует wget (довольно стандартная утилита, но всё же), а lor — fortune.
После debuild можно точку не ставить — она переносится на начало нового абзаца, что выглядит довольно некрасиво.
Ещё раз спасибо за статью!
Спасибо, полезно и хорошо расписано.
З.Ы.
/me пустил скупую слезу на тему буквы Ё.
З.Ы.
Вот и всё!
/me пустил скупую слезу на тему буквы Ё.
автору за пост плюс, остальным перед использованием мейнтейнерских скриптов лучше разобраться как они действуют неплохо описано тут: http://women.debian.org/wiki/English/MaintainerScripts
Часто все многообразие возможностей .deb не нужно - в этом случае можно обойтись проще - помещаем в некоторую директорию дерево катологов, которое нужно запаковать в пакет (при установке распаковываться все будет в корень, нужно иметь это ввиду). Далее создаем директорию DEBIAN и в ней файл control с примерно следующим содержанием (минимальный вариант, по необходимости добавляем свои поля):
И запаковываем все это дело в пакет командой dpkg -b . ../my-prog.deb
Package: my-program
Maintainer: My_name
Architecture: i386
Version: 1
Description: description for my package
И запаковываем все это дело в пакет командой dpkg -b . ../my-prog.deb
dh_make --createorig -c gpl3 -e [email protected] -i -p lorquotes_0.1
А в моём Debian'е нет опции -i у dh_make.
$ dh_make --createorig -c gpl3 -e [email protected] -i -p depends-store_0.1
Unknown option: i
dh_make - Script to Debianize a regular source archive, version 0.46
Потом, по правилам разработчиков Debian директорию для сборки пакета принято называть -. Имя пакета по этим же правилам не может содержать "_". Кроме того, у меня не нашлось лицензии gpl3. Есть просто gpl.
В общем, статья хорошая(сам так же делаю, потому что всяческих скриптиков-костылей куча :)), но стоит уточнить, для какого дистрибутива всё, указанное здесь. На Debian Lenny - не работает.
$ uname -a
Linux virthost 2.6.26-2-openvz-amd64 #1 SMP Mon Oct 19 03:17:12 UTC 2009 x86_64 GNU/Linux
$ cat /etc/debian_version
5.0.3
У меня Debian unstable.
Вместо «-i» можно вводить «--indep». Или вообще пропустить эту опцию, тогда dh_make сам спросит. Если это скрипты, надо будет просто сказать, что пакет от архитектуры не зависит.
Лицензию также указывать необязательно. Это просто для создания заглушки. Можно потом что угодно написать в соответствующем файлике в каталоге «debian/».
Как называть директорию для сборки пакета вообще говоря, непринципиально. Через опцию «-p» можно указать своё имя. Это может быть полезно, когда имя содержит дефис, т.к. имени директории дефис служит для отделения версии. А знак подчёркивания действительно не должен присутствовать в имени пакета, так как в имени версия отделяется именно почёркиванием. Путаница, да.
Вместо «-i» можно вводить «--indep». Или вообще пропустить эту опцию, тогда dh_make сам спросит. Если это скрипты, надо будет просто сказать, что пакет от архитектуры не зависит.
Лицензию также указывать необязательно. Это просто для создания заглушки. Можно потом что угодно написать в соответствующем файлике в каталоге «debian/».
Как называть директорию для сборки пакета вообще говоря, непринципиально. Через опцию «-p» можно указать своё имя. Это может быть полезно, когда имя содержит дефис, т.к. имени директории дефис служит для отделения версии. А знак подчёркивания действительно не должен присутствовать в имени пакета, так как в имени версия отделяется именно почёркиванием. Путаница, да.