Блог об использовании свободной ОС Linux в повседневной жизни, о настройке и др.
среда, 29 октября 2008 г.
Сборка пакетов из исходников в Debian
В Debian можно довольно легко сделать систему управления пакетами со сборкой из исходников (как, например, в Gentoo и др). Для этого надо всего-лишь установить пакет apt-build. При установке вам будут заданы некоторые вопросы по настройке программы, такие как архитектура вашего процессора (набор команд под которые будет оптимизирован исполняемый код), добавлять ли папку с собранными пакетами в список репозиториев обычного apt и др. После этого можно, например, пересобрать всю систему заново из исходников командой (не советую, потратите много времени):
# apt-build world
Или можно использовать программу как замену обычного apt-get. Например, для сборки оптимизированной версии Amarok и его незамедлительной установки можно воспользоваться командой:
# apt-build install amarok
После чего программа скачает все необходимые исходники, соберет пакеты, оптимизированные под вашу архитектуру, и установит эти пакеты.
Ubuntu 22.04 — Установка программ из исходных кодов
Нужно как-нибудь провести сравнительное тестирование программ стандартной сборки и собранных из исходников.
Предыдущий вариант подходит больше для энтузиастов, выжимающих из системы максимум. А что, если нужно кое-что изменить в исходниках программы, добавить собственные настройки по-умолчанию и т.п.? Тогда можно воспользоваться следующим методом.
1. Устанавливаем зависимости для сборки нужного нам пакета:
# apt-get build-dep имя_пакета
2. Скачиваем исходный код пакета (исходники скачаются и распакуются в текущую папку):
# apt-get source имя_пакета
3. В текущей папке появится каталог с исходниками программы и необходимыми скриптами для сборки пакета, называться будет: имя_программы-версия. Производим желаемые изменения в исходниках программы.
4. Для сборки пакета из папки с исходниками (./имя_пакета-версия) нужно выполнить:
# debian/rules binary
И в текущем каталоге окажется собранный пакет. Его можно тут же установить:
# dpkg -i ../имя_собранного_пакета.deb
Источник: dmitriy-trt.blogspot.com
Записки дебианщика
В этом блоге публикуются заметки и решения, найденные в процессе работы, освоения и жизни в дистрибутиве Debian GNU/Linux.
Репозиторий deb-пакетов своими руками: сборка пакетов в Debian из исходников и бинарников на скорую руку
Распаковка существующих пакетов
Сначала посмотрим, что внутри пакета deb или rpm.
Распаковка deb-пакета
Распаковать пакет Debian нужно в два этапа — сначала извлекаем из него файлы, а потом добираемся до собственно бинарников. Вскрываем пакетик:
# ar vx mypackage.deb
- debian-binary — это текстовый файл, который содержит информацию о версии пакета (например: 2.0)
- control.tar.gz — этот архив содержит всю мета-информацию: имя и версию пакета, зависимости и прочее.
- data.tar.gz — собственно, бинарники программы, необходимые для работы. Именно эти файлы будут разархивированы в каталог /usr для дальнейшего использования.
$ tar -xzvf data.tar.gz
В текущем каталоге появится ./usr текущего каталога. Желанный бинарник лежит в ./usr/bin подкаталоге.
Научись Linux: сборка программ из исходников (эпизод 13)
Если же вам нужно просто извлечь файлы из пакета, можно всё сделать одной командой
$ ar p mypackage.deb data.tar.gz | tar zx
это распакует пакет deb в текущий каталог. Другой вариант — использовать dpkg-deb в виде:
$ dpkg-deb -x что.deb куда/
Распаковка rpm-пакета
На всякий случай о том, как распаковать пакеты вероятного противника RPM-based систем. Для этого нам потребуются программы rpm2cpio и cpio. Распаковка содержимого RPM пакета делается в один шаг:
$ rpm2cpio mypackage.rpm | cpio -vid
Если же нужно просмотреть содержимое пакета, не распаковывая его, даём команду:
$ rpm2cpio mypackage.rpm | cpio -vt
Для того, чтобы (попытаться) конвертировать RPM-пакет в Debian, можно воспользоваться командой:
# alien mypack.i386.rpm
Надо сказать, что пакеты RPM и DEB сильно отличаются друг и друга, и такое простое конвертирование не всегда проходит.
Deb-пакет из бинарного файла
Теперь, когда мы знаем, что ничего волшебного внутри deb-пакетов нет, можно попробовать сварганить свой собственный дебиановский пакетик.
Часто хочется сделать побыстрее, чтоб «завелось и поехало» — и вместо пакетов пользователи устанавливают программы в виде ./configure, make = версия)) Recommends: рекомендации (пакет (>= версия)) Suggests: предложения (пакет) Section: секция (multimedia, games, system, или другое) Priority: приоритет (optional) Homepage: http://www.домашняя_страница Description: описание программы
Таким образом, в нашем локальном каталоге ./tempprog будет лежать вот что:
. ├── DEBIAN │.. └── control └── usr └── bin └── fossil 3 directories, 2 files
Теперь из каталога ./tempprog даём команду на сборку этого простенького пакета:
В результате появится пакет (в нашем примере с fossil) вида:fossil_1.21_i386.deb
который можно сразу же установить в систему:
$ sudo dpkg -i fossil_1.21_i386.deb [sudo] password for starscream: Selecting previously deselected package fossil. (Reading database . 247627 files and directories currently installed.) Unpacking fossil (from fossil_1.21_i386.deb) . Setting up fossil (1.21) .
И всё, наступает счастье.
Небольшое примечание: если кто хочет установить программу в директорию
/opt/ нужно сделать следующее:— В локальном каталоге ./tempprog создаём каталог /opt/ и размещаем там
программу так, как она и будет установлена в /opt
— Там же, в ./tempprog создаём подкаталоги /tempprog/usr/bin/
в котором размещаем небольшой скрипт, например zotero
— В нём пишем:#! /bin/sh PATH=$PATH:/opt/zotero/ /opt/zotero/zotero
Это говорит системе, что теперь можно запускать файлы и из /opt/zoteroDeb-пакет из исходников на скорую руку
Здесь приводится простой вариант упаковки исходников, если все зависимости уже на месте и нам ничего не нужно делать. В общем случае это не так, и сборка пакетов с прописыванием зависимостей представляет собой довольно нетривиальный процесс.
Если нам повезло и все зависимости уже в системе, можно скомпилировать исходные тексты программы и по-быстрому завернуть всё в пакет Debian.
Для этого скачанные исходные тексты программы (для примера foobar версии 1.2.3) распаковываем в каталог foobar-1.2.3, и от рута даём команду:
# dh_make —createorig
Далее пишем
Опять, если нам повезло, всё должно собраться без вопросов. Полученный пакет устанавливаем# dpkg -i foobar_1.2.3-1_i386.deb
Охочим до тонкостей дебиановской кулинарии и прочим правильно писающим мальчикам просьба пройти сюда и насладиться The Debian Administrator’s Handbook. Эта Книга о вкусной и здоровой пище довольно занудная, водянистая и словоохотливая книжеца от двух дебианщиков расскажет вам о Debian Policy, как всё делать ортодоксально и, когда авторы вспоминают, что не мемуары пишут, про то, что же таки собственно делать.
Создание собственного локального репозитория Debian своими руками
Когда количество собственноручно собранных пакетов перевалит за десяток, захочется удобства и комфорта установки софта. К счастью, создание собственного локального репозитория — дело сравнительно простое.
Создаём каталог, в котором будут лежать все собранные непосильным трудом пакеты — пусть это будет ~/zips/virensdebianrepositor в который копируем deb-пакеты.
Для создания репозитория нам понадобится dpkg-scanpackages который является (во всяком случае на момент написания поста) частью пакета dpkg-dev, как это неожиданно выяснилось.
Создаём список пакетов:
$ dpkg-scanpackages . /dev/null | gzip -9c > ./Packages.gz
Может быть, нам будет выведено сообщение типа:
dpkg-scanpackages: warning: Packages in archive but missing from override file: dpkg-scanpackages: warning: fossil linux-headers-3.8.0-avl9-pae linux-image-3.8.0-avl9-pae pdfsam sublimetext virtualbox-4.2 xserver-xorg-input-wacom zotero dpkg-scanpackages: info: Wrote 8 entries to output Packages file.
Теперь в нашем репозитории 8 пакетов. Отлично, добавляем наш репозиторий в файл:# vim /etc/apt/sources.list
deb file:///home/имя_пользователя/zips/virensdebianrepository ./
Теперь нужно обновить список пакетов, чтобы они стали доступны для установки:# apt-get update
Всё, теперь можно установить, к примеру, свежесобранный текстовый редактор Sublime Text 2 (отличная инструкция там) как всегда: Теперь, для того, чтобы установить SublimeText достаточно сделать:
# apt-get install sublimetext
Reading package lists. Done Building dependency tree Reading state information. Done The following NEW packages will be installed: sublimetext 0 upgraded, 1 newly installed, 0 to remove and 245 not upgraded. Need to get 0 B/11.4 MB of archives. After this operation, 17.4 MB of additional disk space will be used. WARNING: The following packages cannot be authenticated! sublimetext Install these packages without verification [y/N]?
Y Selecting previously deselected package sublimetext. (Reading database . 247813 files and directories currently installed.) Unpacking sublimetext (from . /./sublimetext_2.0.2_i386.deb) . Setting up sublimetext (2.0.2) .
Всё, пакет будет распакован и установлен, а то, что он из местного репозитория, видно вот тут: (from . /./sublimetext_2.0.2_i386.deb)
Заключение
Описанные в этом посте рецепты — блюда на скорую руку, а не фуагра с трюфелями. Для больших репозиториев или сложных пакетов придётся-таки ознакомиться с документацией и руководствами. Ещё можно воспользоваться программой APTonCD, которая умеет не только создавать репозитории, но и записывать их на CD/DVD диски.
17 комментариев: |высказаться!| RSS-лента дискуссии.|
Vlsu комментирует. 14 окт. 2013 г., 05:01:00
Очень полезный пост. Для убунты пару раз собирал репозитории, а вот до дебиана руки не доходили. А тут уже подробное руководство 🙂
Кстати, точно помню, что в убунте можно было воспользоваться приблудой под названием APTonCD. Репозиторий делала немножко коряво, но зато позволяла в пару кликов сделать репозиторий из кеша APT. Думаю, что о ней стоит упомянуть
Очень полезный пост.
Дык, а то! Баянист со стажем, шо ж ты хочешь. 🙂Для убунты пару раз собирал репозитории, а вот до дебиана руки не доходили.
А там всё одно и тоже. Кстати, в комментариях рецептиками не поделишься?Кстати, точно помню, что в убунте можно было воспользоваться приблудой под названием APTonCD. Репозиторий делала
Зачем на CD? Мне просто локальный репозиторий сделать, записывать не надо. Но согласен — упомянуть стоит.
А вообще джедаи идут другим путём. 🙂Отдельное спасибо тов. brainstream, который указал на баг в посте с отрисовкой окружения PRE. Такое бывает, когда доверяешь хаскельным поделкам вроде pandoc 🙂
Да, если есть что добавить — пишите в комментариях, но учтите, что пост — именно на скорую руку, без нужды перечитывать фолианты Debian Packaging Guidelines и прочую квантовую физику.
Ошибка у вас в тексте:
«Теперь, для того, чтобы установить Skype достаточно сделать:# apt-get install sublimetext «
Распаковывать пакеты можно через dpkg-deb:
$ dpkg-deb -x что.deb куда/Всегда использовал dpkg -e и dpkg -x для полной распаковки пакета и быстрой правки файлов или зависимостей в контрольных файлах. А так же использовал checkinstall вместо make install для создания пакета при компиляции чего либо. Мне кажется эти утилиты стоит упомянуть.
Ошибка у вас в тексте:
Есть такое. Исправил.Распаковывать пакеты можно через dpkg-deb
Добавил в пост. Спасибо.А так же использовал checkinstall
Упомянул. Самая главная проблема начинающих дебианщиков (и особенно убунтушников) — установка программ через make install, в обход менеджера пакетов. Потом они рыдают в три ручья на форумах.Сборка пакетов из исходников в Debian — это от лукавого! Я сейчас припомню свой опыт:
1. В deb-пакете должны быть прописаны майнтейнер и прочая чепуха, без которой (сюрприз-сюрприз!) пакет не соберется.
2. Вы собрали, установили и думаете, что на этом всё? Не тут-то было, добрый aptitude может снести пакет ко всем чертям при установке чего-то другого. Вам знакомо такое чувство: как? где? что? я же уже ставил этот пакет. Ну вот такой он aptitude — весь из себя православный, а значит, патриархальный и вольнодумства не позволяющий.
3. Поэтому срочно необходим маневр: aptitude hold package. «Что, хорошо держится? А теперь будьте любезны — отлепите!» (с) Поскольку с этого момента aptitude будет ругаться, что он не в состоянии разрулить зависимости, не снеся вашего пакета.
4. На этом нервы мои сдали. И я открыл для себя Gentoo, а мои волосы снова стали мягкими и шелковистыми!
1. В deb-пакете должны быть прописаны майнтейнер и прочая чепуха
Стандартное policy — надо же знать, кому дать в морду за сломанный пакет 🙂 И потом, это всяко лучше того бедлама, который творится в RPM-ных федорах и зюзях.2. Вы собрали, установили и думаете, что на этом всё? Не тут-то было, добрый aptitude может снести пакет ко всем чертям при установке чего-то другого.
Только если ты ставишь пакет старой версии — например, у меня стоит hold на IceWM, который я поставил из Lenny (придурок-майнтейнер запихнул в Squeeze айс с отломанным треем). Аптитуда тебя предупредит перед подобными манёврами, если что.3. Поэтому срочно необходим маневр: aptitude hold package. aptitude будет ругаться, что он не в состоянии разрулить зависимости
Это ложь и провокация: только если ты не влепил hold на что-нибудь типа gcc или glibc, нормально оно разруливать зависимости будет. В отличие от RPM-ов, которые любят сдаваться сразу в стиле «Ну не шмогла я, не шмогла» 🙂Проблемы с разруливанием зависимостей могут быть, это факт, но это лучше, чем жарить яичницу с беконом на процессоре в ожидании конца конпеляния гентой свежего KDE.
4. На этом нервы мои сдали.
Как-то ты быстро сдулся. Кстати, а как дела с зависимостями в генте? Как вы там живёте-то с конпелянием на каждый чих?
Я это. не троллинга ради. народ интересуется.Кстати, а как дела с зависимостями в генте?
Чтобы сломать зависимости на стабильной ветке, нужно очень постараться.Как вы там живёте-то с конпелянием на каждый чих?
Для страждущих есть репозитории с бинарными пакетами.Я это. не троллинга ради.
Так я и вижу, что троллинга не получилось. Тролли нынче не те, видно, завалены основной работой.зоркие блюстители лицензионной чистоты дебиана не дремали,
Ну как бы у них есть, чего опасаться. Мелкософты всякие с ораклами могут взять за жабры и пустить ко дну.гента — это свобода, а в дебиане свободы не больше, чем в православном монастыре.
Ну почему: всегда можно пойти по пути Слакварщика и начать конпелять в обход APT. И будет тебе православно, патрикоугодно и ортодоксально. Правда, до следующего апдейта, да.Чтобы сломать зависимости на стабильной ветке, нужно очень постараться.
Тут тоже всё более или менее предсказуемо.Тролли нынче не те, видно, завалены основной работой.
А я на диете малой жирности — худею, в комментариях не троллю.
Работы, кстати, на удивление почти нет — ждём-с ответа на наш грант, и будем ли мы распиливать бюджет. In the meantime я ваяю скрипты для автоматизации на Тикле (Tcl) — отличная штука, между прочим! После короткого вкуривания мануалов (весьма дерьмовых, кстати) пишется легко и между прочим, работает быстро и даже графический интерфейс можно прилепить (правда он страшен, как смерть водолаза).Можно открыть дискас на тему «Tcl VS LISP VS Lua VS Ruby» 😉
В тексте ошибка — пропущено слово:
. пакетный менеджер ничего о них не будет, и при обновлении системы.Теперь стОит ждать посты про Tcl/Tk? 😉
В тексте ошибка — пропущено слово
Есть такое — исправил. Благодарствую.Теперь стОит ждать посты про Tcl/Tk? 😉
Собственно, они уже в пути, прибывают на первую платформу по расписанию 🙂Тикль, кстати, хорош всем, кроме некоторых встроенных косяков (он интерпретирует комментарии в коде!) и убогой (и крайне малочисленной) документации. Всего две-три книги, месиво вместо вики и пара туториалов.
Собираю fpm-ом (https://github.com/jordansissel/fpm) Рекомендую!
Хм. на Хабре про этот fpm статья тоже вышла буквально совсем недавно. Сетевой маркетинг? 😉
Deb-пакет из бинарного файла
очень много моментов опущено:
Первое владельцем всех каталогов и файлов внутри ./tempprog должен быть root из группы root . Права на все файлы и каталоги 755
Второе Если бинарник идёт в автозапуск целесообразно набросать скриптик /DEBIAN/postinst а архитектура бинарника должна соответствовать /DEBIAN/control
Третье если собирать в домашнем каталоге команда из папки
:~/tempprog$ sudo dpkg-deb -b ./ ~/.
соответственно получаемый пакет генерируется каталогом выше.
Если собирать командой из статьи внутри пакета получается одноимённый файл, который там абсолютно не нужен.
В общем и целом конечно идея неплохая.Источник: mydebianblog.blogspot.com
Глава 15. Создание пакета Debian
Нередко администратор, постоянно имеющий дело с пакетами Debian, со временем чувствует необходимость в создании своих собственных пакетов или изменении существующего пакета. Цель этой главы состоит в том, чтобы ответить на наиболее распространенные вопросы в этой области, а также предоставить необходимые базовые знания для использования инфраструктуры Debian наилучшим образом. Если повезет, после попытки приложить руку к созданию локальных пакетов вы даже можете почувствовать потребность в том, чтобы пойти дальше и присоединиться к самому Проекту Debian!
15.1. Пересборка пакета из его исходного кода
Пересборка двоичного пакета требуется при ряде обстоятельств. В некоторых случаях администратору нужна функциональность программы, для активации которой необходима компиляция из исходного кода с определенной опцией; в других программное обеспечение, упакованное в установленной версии Debian, недостаточно актуально. В последнем случае администратору обычно нужно собрать более свежий пакет, взятый из более новой версии Debian — например Testing или даже Unstable — чтобы новый пакет заработал в дистрибутиве Stable ; эта операция называется «бэкпортирование». Как обычно, прежде чем приступать к такой задаче, следует проверить, не был ли такой пакет уже создан, — для этого достаточно беглого взгляда на страницу данного пакета в Системе отслеживания пакетов Debian.
15.1.1. Получение исходного кода
Rebuilding a Debian package starts with getting its source code. The easiest way is to use the apt-get source package-name command. This command requires a deb-src line in the /etc/apt/sources.list file, and up-to-date index files (i.e. apt-get update ). These conditions should already be met if you followed the instructions from the chapter dealing with APT configuration (see Раздел 6.1, «Содержимое файла sources.list »). Note, however, that you will be downloading the source packages from the Debian version mentioned in the deb-src line.
If you need another version, you may need to download it manually from a Debian mirror or from the web site. This involves fetching two or three files (with extensions *.dsc — for Debian Source Control — *.tar.comp , and sometimes *.diff.gz or *.debian.tar.comp — comp taking one value among gz , bz2 or xz depending on the compression tool in use), then run the dpkg-source -x file.dsc command. If the *.dsc file is directly accessible at a given URL, there is an even simpler way to fetch it all, with the dget URL command.
This command (which can be found in the devscripts package) fetches the *.dsc file at the given address, then analyzes its contents, and automatically fetches the file or files referenced within. Once everything has been downloaded, it verifies the integrity of the downloaded source packages using dscverify , and it extracts the source package (unless the -d or —download-only option is used). The Debian keyring is needed, unless the option -u is supplied.
15.1.2. Внесение изменений
Для примера возьмём пакет samba .
$ apt source samba Reading package lists. Done NOTICE: ‘samba’ packaging is maintained in the ‘Git’ version control system at: https://salsa.debian.org/samba-team/samba.git Please use: git clone https://salsa.debian.org/samba-team/samba.git to retrieve the latest (possibly unreleased) updates to the package. Need to get 12.3 MB of source archives. Get:1 http://security.debian.org/debian-security bullseye-security/main samba 2:4.13.13+dfsg-1~deb11u3 (dsc) [4,514 B] Get:2 http://security.debian.org/debian-security bullseye-security/main samba 2:4.13.13+dfsg-1~deb11u3 (tar) [11.8 MB] Get:3 http://security.debian.org/debian-security bullseye-security/main samba 2:4.13.13+dfsg-1~deb11u3 (diff) [468 kB] Fetched 12.3 MB in 3s (4,582 kB/s) dpkg-source: info: extracting samba in samba-4.13.13+dfsg dpkg-source: info: unpacking samba_4.13.13+dfsg.orig.tar.xz dpkg-source: info: unpacking samba_4.13.13+dfsg-1~deb11u3.debian.tar.xz dpkg-source: info: using patch list from debian/patches/series dpkg-source: info: applying 07_private_lib dpkg-source: info: applying bug_221618_precise-64bit-prototype.patch dpkg-source: info: applying [. ]
The source of the package is now available in a directory named after the source package and its version ( samba-4.13.13+dfsg ); this is where we’ll work on our local changes.
The first thing to do is to change the package version number, so that the rebuilt packages can be distinguished from the original packages provided by Debian. Assuming the current version is 2:4.13.13+dfsg-1~deb11u3 , we can create version 2:4.13.13+dfsg-1~deb11u3+falcot1 , which clearly indicates the origin of the package. This makes the package version number higher than the one provided by Debian, so that the package will easily install as an update to the original package. Such a change is best effected with the dch command ( Debian CHangelog ) from the devscripts package.
$ cd 4.13.13+dfsg-1~deb11u3 $ dch —local +falcot
Последняя команда вызывает текстовый редактор ( sensible-editor — это должен быть ваш любимый редактор, если он указан в переменной окружения VISUAL или EDITOR , а в противном случае редактор по умолчанию) для того, чтобы документировать изменения, внесенные данной пересборкой. Этот редактор показывает нам, что dch действительно изменила файл debian/changelog .
When a change in build options is required, the changes need to be made in debian/rules , which drives the steps in the package build process. In the simplest cases, the lines concerning the initial configuration ( ./configure … ) or the actual build ( $(MAKE) … or make … or cmake … or …) are easy to spot. If these commands are not explicitly called, they are probably a side effect of another explicit command, in which case please refer to their documentation to learn more about how to change the default behavior. With packages using dh , you might need to add an override for the dh_auto_configure or dh_auto_build commands (see their respective manual pages and debhelper (7) for explanations on how to achieve this).
В зависимости от локальных изменений в пакетах может потребоваться также обновление файла debian/control , который содержит описание создаваемых пакетов. В частности, этот файл содержит строки Build-Depends , контролирующие список зависимостей, которые должны быть удовлетворены на этапе сборки пакета. Они часто ссылаются на версии пакетов, содержащиеся в дистрибутиве, откуда взят исходный код, но которые могут быть недоступны в дистрибутиве, используемом для пересборки. Не существует автоматизированного способа определить, является ли зависимость реальной, или же она указана только с целью гарантировать выполнение сборки исключительно с последней версией библиотеки, — это единственный доступный способ заставить autobuilder использовать данную версию пакета во время сборки, из-за чего сопровождающие Debian часто используют строго версионированые сборочные зависимости.
Если вы точно знаете, что эти сборочные зависимости слишком строги, не стесняйтесь ослабить их локально. Чтение файлов, документирующих стандартный способ сборки программного обеспечения — эти файлы часто называют INSTALL — поможет выяснить соответствующие зависимости. В идеале все зависимости должны быть удовлетворены из дистрибутива, используемого для пересборки; в противном случае начинается рекурсивный процесс, в результате которого пакеты, упомянутые в поле Build-Depends , должны быть бэкпортированы раньше целевого пакета. Некоторые пакеты могут не требовать бэкпортирования, и их можно установить как есть в процессе сборки (ярким примером является debhelper ). Обратите внимание, что процесс бэкпортирования может стать лавинообразным, если вы не будете осторожны. Поэтому бэкпорты должны быть сведены к абсолютному минимуму, насколько это возможно.
СОВЕТ Установка Build-Depends
apt-get allows installing all packages mentioned in the Build-Depends fields of a source package available in a distribution mentioned in a deb-src line of the /etc/apt/sources.list file. This is a simple matter of running the apt-get build-dep package command.
15.1.3. Запуск пересборки
Когда все необходимые изменения внесены в исходный код, мы можем запустить создание собственно двоичного пакета (файл .deb ). Весь процесс управляется командой dpkg-buildpackage .
Пример 15.1. Пересборка пакета
$ dpkg-buildpackage -us -uc [. ]
The previous command can fail if the Build-Depends field has not been updated, or if the related packages are not installed. In such a case, it is possible to overrule this check by passing the -d option to dpkg-buildpackage . However, explicitly ignoring these dependencies runs the risk of the build process failing at a later stage. Worse, the package may seem to build correctly but fail to run properly: some programs automatically disable some of their features when a required library is not available at build time. The switch can still be very useful if you only want to create a source package, which is supposed to be passed to clean build environments as described in QUICK LOOK Building packages in chrooted and virtual environments.
The other options used in the above example make sure that neither the source package’s .dsc ( -us ) nor the produced .changes file ( -uc ) get signed with the package builder’s cryptographic key after the asuccessful build.
ИНСТРУМЕНТ fakeroot
В сущности процесс создания пакета является простым сбором в архив набора существующих (или скомпилированных) файлов; большинство файлов архива будут иметь в конечном итоге владельца root . Тем не менее, сборка всего пакета от имени этого пользователя подразумевала бы повышенный риск; к счастью, этого можно избежать с помощью команды fakeroot . Этот инструмент может быть использован для запуска программы и создания у неё впечатления, что она запущена от имени root и создает файлы с произвольным владельцем и правами. Когда программа создает архив, который станет пакетом Debian, она хитрым образом внедряется в процесс создания архива, содержащего файлы, помеченные как принадлежащие произвольным владельцам, в том числе root . Это поведение настолько удобно, что dpkg-buildpackage использует fakeroot по умолчанию при сборке пакетов.
Заметьте, что программу только заставляют «поверить» в то, что она работает под привилегированной учетной записью, но процесс на самом деле выполняется от имени пользователя, запустившего fakeroot программа (и права на создаваемые файлы в действительности принадлежат этому пользователю). Фактически программа ни в какой момент времени не получает привилегий суперпользователя, которыми могла бы злоупотреблять.
More often than not, Debian developers use a higher-level program such as debuild ; this runs dpkg-buildpackage as usual, but it also adds an invocation of a program that runs many checks to validate the generated package against the Debian policy. This script also cleans up the environment so that local environment variables do not “pollute” the package build. The debuild command is one of the tools in the devscripts suite, which share some consistency and configuration to make the maintainers’ task easier.
QUICK LOOK Building packages in chrooted and virtual environments
Building a package on an existing system, like a workstation or server, can pose several problems. Maybe the system has packages installed, that conflict with the build requirements. Or maybe it has packages (libraries, headers, etc.) installed, that the project to build is not supposed to use — e.g. from Testing , Unstable , or even from third parties. Also it might have packages installed, which are actually required for the build, but are not listed in debian/control . It is therefore a good practice to build a packages in “clean“ environments.
The sbuild , pbuilder , or cowbuilder programs (in the similarly named packages) allow building a Debian package in a chrooted environment. Each of them first creates a temporary directory containing the minimal system required for building the package (including the packages mentioned in the Build-Depends field). This directory is then used as the root directory ( / ), using the chroot command, during the build process.
These tools allow the build process to happen in an environment that is not altered by users’ manipulations. This also allows for quick detection of the missing build-dependencies (since the build will fail unless the appropriate dependencies are documented). Finally, it allows building a package for a Debian version that is not the one used by the system as a whole: the machine can be using Stable for its normal workload, and the chrooted environments can be running on the same machine using Unstable for package builds. Using these tools, it is also possible to build for a different distribution, like Ubuntu .
schroot , sbuild-shell , or pbuilder allow running a command or a login shell in a chrooted environment.
Sometimes it is not enough to build a package in a chrooted environment. This can be due to building for a different architecture where cross-compilation does not work, or due to the tools not being able to create a chrooted environment for the desired target system. Then one can create virtual machines to build the package there. These setups are usually more complex then the tools mentioned above, and rarely needed, so we will only mention this possibility without going into much detail. Check out Раздел 12.2, «Виртуализация» for an introduction into this topic.
Источник: debian-handbook.info
