Сборка deb-пакета
Как уже неоднократно мне говорил Григорий (он же OM), для поддержания системы в актуальном состоянии достаточно обновлять только те несколько программ, которые чаще всего используешь. Потихоньку начинаю понимать данную философию. И с переходом на Ubuntu озадачился сборкой новых версий программ.
Систему нужно подготовить к сборке, для этого устанавливаем следующие пакеты:
$ sudo aptitude install dpkg-dev autoconf automake
При этом желательно устанавливать рекомендуемые пакеты, как зависимости, чтобы подтянулись все остальные, нужные для работы, пакеты. После чего необходимо в ~/.bashrc добавить следующие строки:
export DEBFULLNAME='Denis Evsyukov' export DEBEMAIL=mymail@gmail.com
В принципе это не обязательное условие, но исходя из значений данных переменных формируется информация о пакете, и ищется ключ для подписи пакета.
Теперь для примера рассмотрим сборку Midnight Commander версии 4.7.0-pre4. В темповой директории создаем отдельную папку для работы:
$ mkdir ~/Temp/mc
И загружаем в нее исходники с официального сайта. Распаковываем их, архив с исходниками оставляем на месте. Читаем файл INSTALL, где обычно указываются пакеты, необходимые для сборки, и если их в системе нет, устанавливаем. После чего выполняем следующие команды:
~/Temp/mc$ cd mc-4.7.0-pre4 ~/Temp/mc/mc-4.7.0-pre4$ dh_make -f ../mc-4.7.0-pre4.tar.bz2 ~/Temp/mc/mc-4.7.0-pre4$ vim debian/control ~/Temp/mc/mc-4.7.0-pre4$ rm debian/*.ex ~/Temp/mc/mc-4.7.0-pre4$ dpkg-buildpackage -rfakeroot
Первой командой переходим в директорию с исходниками. Второй командой подготавливаем служебные файлы, здесь обязательно указывать архив с исходными файлами, которые распаковывали. Во время исполнения данной команды нас спросят, что именно мы собираемся собирать, в нашем случае мы собираем одиночный пакет, поэтому жмем s и затем после просмотра значений, жмем Enter. Третьей командой необходимо изменить файл debian/control, приводим его примерно к следующему виду:
Source: mc
Section: utils
Priority: extra
Maintainer: Denis Evsyukov <mymail@gmail.com>
Build-Depends: debhelper (>= 7), autotools-dev
Standards-Version: 3.8.1
Homepage: http://www.juev.ru
Package: mc
Architecture: amd64
Depends: ${shlibs:Depends}, ${misc:Depends}
Description: <insert up to 60 chars description>
<insert long description, indented with spaces>
При использовании редактора vim, ошибки будут подсвечиваться красным, что довольно удобно. Поле Maintainer заполняется исходя из значений переменных, которые мы задали в файле ~/.bashrc чуть ранее. Изменяем поля Section, прописывая в какой группе программ будет располагаться наш пакет, задаем домашнюю страницу, если она есть, обязательно меняем архитектуру с any на свою (x86 или amd64), иначе сборка не будет завершена корректно и последним шагом задаем описание пакета, в примере оно не заполнено.
Закрываем файл, сохранив изменения и удаляем в папке debian все файлы c расширением ex, они для сборки не нужны. Если это необходимо, можно поправить файл debian/rules, прописав нужные опции в строке с configure. И завершающим шагом собираем пакет, дав последнюю команду из приведенного выше списка.
Результатом наших действий является deb-пакет, который будет располагаться в родительской директории, в нашем случае это ~/Temp/mc. Просто устанавливаем его, для того, чтобы начать использовать программу:
~/Temp/mc$ sudo dpkg -i mc_4.7.0-pre4-1_amd64.deb
Собственно все! Единственно, что мне так и не удалось сделать – это подписать пакет своим ключом и объяснить системе, что установленный пакет является более новым, чем тот, что располагается в репозитории. Ключ он пока просто не находит, хотя gpg работает с ним без проблем, а с пакетным менеджером я еще не разбирался так плотно.
для установки зависимстей можно воспользоваться командой типа:
apt-get source packagename
подписать пакет можно через
$dpkg-buildpackage -k
такое чуство что gpg ищет ключ по точному совпадению Имя , и не учитывает что может быть комментарий.
$dpkg-buildpackage -k123
где 123 – номер ключа
Данная команда, если я правильно помню вытягивает исходники программы с необходимыми зависимостями. В то же время, если собираем пакет более новой версии, чем находится в репо, то данная команда не поможет.
И для установки необходимых пакетов (зависимостей) все таки придется поработать ручками.
Да, спасибо! Как оказалось, я неверно указал последовательность имени, фамилии… Тут требуется точное совпадение. После изменения параметров переменных пакет подписался.
Осталось разобраться, как сделать так, чтобы пакетный менеджер не считал пакет из репо более предпочтительным, чем установленный вручную…
полагаю apt_preferences ?
или просто собрать с бОльшим номером версии.
Больший номер версии уже используется, но пакетный менеджер пытается ставить из репо, пусть и более старую версию…
А вот по поводу apt_preferences надо будет посмотреть, спасибо!
Да, вы оказались правы, достаточно было правильно указать версию пакета, для этого используется команда dch -i и редактирование чейжлога, где указываем новую версию. После сборки и установки пакетный менеджер правильно определяет пакет с более новым программным обеспечением.
Еще раз спасибо!
welcome,
я сам только на днях пакет собирал ))
А зачем городить огород, когда есть checkinstall?
чекинстал конечно проще, но сам пакет, который получается с его помощью очень ущербный…
чтобы не было проблем, лучше воспользоваться данным способом.
Я бы сделал по-другому:
1) идёшь на страницу пакета: http://packages.ubuntu.com/karmic/mc
2) находишь там ссылку на файл .dsc справа, копируешь её в буфер
3) выкачиваешь сорс-пакет:
$ dget http://…./mc_4.6.2-2ubuntu1.dsc
4) распаковываешь полученные три файла:
$ dpkg-source -x mc_4.6.2-2ubuntu1.dsc
получится каталог mc-4.6.2
5) заходишь в него, обновляешь его до новой версии:
$ uupdate ../mc-4.7.0-pre4.tar.bz2
6) если повезло, заходишь в полученный новый каталог:
$ cd ../mc-4.7.0
7) правишь debian/changelog:
$ dch -i
(там нужно указать debian revision в номере пакета, желательно такую, чтоб она была ниже версии мейнтейнера убунты, например, 4.7.0~juev1)
P.S.
Так, конечно, работает не всегда. Например, пакет может содержать патчи, которые в новой версии апстрима уже интегрированы. Но попытаться обновить готовый пакет– более разумное решение, т.к. иногда дебианизация бывает довольно обширной.
Вроде сложнее?? Не?
По крайней мере действий нужно совершить больше. И к тому же, согласно вашему способу можно собрать деб-пакет только того, что есть уже в репо. В случае сборки пакета программы, отсутствующей в репо в любом случае придется пользоваться тем, что я описал. Этот метод более универсальный…
Совсем забыл… Спасибо большое за описание иного способа!
Запишу в копилку, пригодится!
Всё верно.
Я напирал на то, что относительно сложных случаев, когда мейнтейнер готового пакета довольно много сил вложил в дебианизацию, достаточно много, если посмотреть в реальные пакеты.
Соответственно бывает проще «стоять на плечах гигантов», чем париться с тем, что уже укра^Wсделано до нас.
В таком случае, да, вы правы.
Спасибо большое!
Konstantin Khomoutov всё верно написал. Остаётся добавить, что совсем не обязательно пичкать десктоп пакетами, необходимыми для сборки, а также зависимостями. К тому же иногда надо собрать пакет для другой версии Ubuntu/Debian, да и зависимости на «чистой» системе отследить легче. И всю эту радость нам даёт ubuntu-dev-tools:
$ sudo apt-get install ubuntu-dev-tools
$ pbuilder-dist karmic amd64 create
Итак, теперь мы можем строить пакеты на чистом karmic amd64 (на 64-битной ОС можно строить и 32-битные пакеты, но не наоборот).
Итак, собираем пакет:
1. Получаем .dsc пакета. Konstantin Khomoutov всё написал выше, можно только добавить, что по рекомендациям ведущих Дебунтоводов собственный пакет нужно нумеровать таким образом, чтобы пакет той же версии из родного репозитория получил приоритет чуть выше нашего. Соответственно пример для mc:
Родной пакет: 4.6.2-2ubuntu1
Если выйдет родной 4.7: 4.7.0-1*****
Значит мы делаем 4.7.0-1~juev1, потом juev2, juev3 и так далее. Если через годик так повезёт, что в родном Дебунтовском репо появится 4.7, он появится под версией 4.7.0-1 (или 4.7.0-1ubuntu1), а значит будет иметь больший приоритет, чем наш доморощенный, и система спокойно обновится. Пока мы не выпустим 4.7.0-2~juev1, конечно
Впрочем продолжим про сборку пакета. Выполнив все шаги, описанные Костей и мной мы получили файл mc_4.7.0-1~juev1.dsc, так попробуем же его собрать:
$ pbuilder-dist karmic amd64 build ../mc_4.7.0-1~juev1.dsc
Вуа-ля, заглядываем в ~/pbuilder/karmic-amd64_result и видим, что там лежит готовенький к употреблению пакет mc_4.7.0-1~juev1.deb
Аналогично, не отходя от кассы мы можем его собрать и для, например, старенького сервера под управлением HH:
$ pbuilder-dist hadry i386 build ../mc_4.7.0-1~juev1.dsc
Результат будет, соответственно, покладен в ~/pbuilder/hardy-i386_result
Третий шаг, который нам теперь надо сделать – опубликовать наш пакет в собственном репозитории. Но что то я не вижу как тут аттачить файлы, а надо опубликовать скрипт… Так что об этом – в следующей серии
Ух ты! Спасибо большое за столь подробное описание!!