Pkg kali linux ���������

Pkg kali linux ���������

pkgng — это усовершенствованный инструмент, пришедший на смену традиционным утилитам управления пакетами FreeBSD. Он обладает множеством функциональных возможностей, ускоряющих и облегчающих работу с бинарными пакетами. Первый релиз pkgng состоялся в августе 2012 года.

pkgng не является заменой для утилит управления портами, таких как ports-mgmt/portmaster или ports-mgmt/portupgrade. В то время, как ports-mgmt/portmaster и ports-mgmt/portupgrade позволяют устанавливать приложения сторонних разработчиков как из бинарных пакетов, так и из Коллекции Портов, утилита pkgng дает возможность устанавливать приложения исключительно из бинарных пакетов.

Начало работы с pkgng

Во FreeBSD 9.1 и более поздние включена программа «самонастройки» («bootstrap») pkgng. Она скачивает и устанавливает основную утилиту pkgng.

Для запуска самонастройки, выполните:

Для более ранних версий FreeBSD утилиту pkgng необходимо установить из Коллекции Портов или из бинарных пакетов.

Для установки pkgng из порта, запустите следующее:

Для установки из бинарного пакета, выполните:

Действующие инсталляции FreeBSD требуют преобразования базы данных установленных пакетов утилиты pkg_install к новому формату. Для выполнения конвертирования, запустите:

Вышеприведенный шаг не требуется для новых инсталляций, в которых не было установлено программ сторонних разработчиков.

Важно:

Этот шаг необратим. После перевода базы данных установленных пакетов к формату pkgng утилитами pkg_install более пользоваться не следует.

Примечание:

В процессе конвертирования базы данных установленных пакетов могут возникать сообщения об ошибках. На данном этапе их можно игнорировать, так как перечень программ сторонних разработчиков, информация о которых не была преобразована, будет перечислен по завершении работы pkg2ng. Над этим перечнем придется поработать вручную.

Чтобы убедиться, что Коллекция Портов FreeBSD регистрирует новые программы при помощи pkgng, а не pkg_install, для версий FreeBSD, предшествующих 10. X, в файл /etc/make.conf необходимо внести следующую запись:

Настройка окружения pkgng

Система управления пакетами pkgng при выполнении большинства операций обращается к пакетному репозиторию. Адрес используемого по умолчанию репозитория указан в /usr/local/etc/pkg.conf или в переменной окружения PACKAGESITE. Последняя переопределяет адрес, указанный в конфигурационном файле.

Дополнительные опции конфигурации pkgng описаны в pkg.conf(5).

Основные операции pkgng

Информацию по работе с pkgng можно найти на странице справочника pkg(8), или в выводе утилиты pkg, запущенной без аргументов.

Каждый аргумент команды pkgng описан на соответствующей странице справочника. Например, чтобы ознакомиться со страницей справочника для pkg install, запустите любую из двух нижеследующих команд:

Получение информации об установленных пакетах при помощи pkgng

Информация об установленных в системе пакетах может быть отображена при помощи команды pkg info. Подобно до pkg_info (1) , в выводе перечисляются версии и описания всех установленных пакетов.

Если необходима информация о конкретном пакете, выполните:

Например, для получения версии pkgng, который установлен в системе, запустите:

Установка и удаление пакетов при помощи pkgng

В общем, бинарные пакеты устанавливаются при помощи:

Команда pkg install обращается к пакетному репозиторию, это упоминалось в Раздел 5.5.2, >. Команда pkg-add(8), напротив, не выполняет обращений к пакетному репозиторию, а также игнорирует переменную PACKAGESITE. Как следствие — зависимости не отслеживаются, и необходимые зависимые компоненты не скачиваются с удаленного источника. В этом разделе описана работа с pkg install. За подробностями работы с pkg add обратитесь к справочной странице по pkg-add(8). Утилита pkg install может устанавливать дополнительные бинарные пакеты. Например, для установки curl, выполните:

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

Пакеты, в которых более нет необходимости, могут быть удалены при помощи pkg delete. Например, если выяснится, что curl не нужен:

Обновление установленных пакетов при помощи pkgng

Пакеты, версии которых устарели, можно найти при помощи команды pkg version. Версии установленных пакетов сравниваются с версиями приложений из локального дерева портов, а в случае отсутствия портов pkg-version(8) обращается к удаленному репозиторию пакетов.

При помощи pkgng можно обновлять пакеты до новых версий. Предположим, вышла новая версия curl. Установленный пакет можно обновить к новой версии, выполнив:

Аудит безопасности пакетов при помощи pkgng

Изредка в приложениях из Коллекции Портов обнаруживаются уязвимости. В pkgng встроена возможность выполнять аудит безопасности, действующая подобно приложению из ports-mgmt/portaudit. Для выполнения аудита установленных в систему программ, выполните:

Сложные вопросы работы с pkgng

Автоматическое удаление неиспользуемых зависимостей при помощи pkgng

После удаления пакета в системе могут остаться неиспользуемые зависимости, наподобие security/ca_root_nss из примера выше. Такие пакеты остаются установленными, несмотря на то, что они более не требуются другим пакетам. Определить и удалить неиспользуемые пакеты, которые были установлены как зависимости, можно при помощи:

Резервное копирование базы данных установленных пакетов pkgng

В отличие от традиционной системы управления пакетами, pkgng располагает своим собственным механизмом резервного копирования базы данных. Для ручного создания резервной копии базы данных установленных пакетов, выполните:

Примечание:

Замените имя файла pkgng.db на более подходящее.

В дополнение, pkgng содержит скрипт periodic (8) , позволяющий выполнять ежедневное автоматическое копирование базы данных установленных пакетов. Для активации данной возможности задайте переменной daily_backup_pkgng_enable значение YES в файле periodic.conf (5) .

Подсказка:

Для предотвращения периодического запуска аналогичного скрипта системы pkg_install, также выполняющего резервное копирование базы данных установленных пакетов, задайте переменной daily_backup_pkgdb_enable значение NO в файле periodic.conf (5) .

Для восстановления содержимого базы данных установленных пакетов из резервной копии, выполните:

Удаление копий устаревших пакетов в системе pkgng

По умолчанию, pkgng сохраняет копии установленных бинарных пакетов в каталог, указанный переменной PKG_CACHEDIR в pkg.conf(5). При обновлении пакетов командой pkg upgrade старые версии обновленных пакетов автоматически не удаляются.

Для удаления устаревших версий бинарных пакетов из кеш-каталога, выполните:

Изменение метаданных пакетов pkgng

Со временем программы из Коллекции Портов могут претерпевать изменения старшего (major) номера версии. В отличие от pkg_install, pkgng располагает встроенной командой для обновления информации о происхождении (origin) пакета. Например, изначально порт lang/php5 был версии 5.3. Позже этот порт был переименован в lang/php53, а под именем lang/php5 был создан порт версии 5.4. Утилитам системы pkg_install для обновления информации о происхождении (origin) пакета в собственной базе данных установленных пакетов потребовалась бы помощь дополнительного программного обеспечения, такого как ports-mgmt/portmaster.

В отличие от ports-mgmt/portmaster и ports-mgmt/portupgrade для портов, порядок перечисления новой и старой версий отличаются. Для pkgng необходим следующий порядок:

Например, в вышеприведенном случае для замены информации о происхождении пакета, выполните:

Еще один пример: для изменения информации о происхождении пакета с lang/ruby18 на lang/ruby19, выполните:

И последний пример: для замены информации о происхождении пакета разделяемой библиотеки libglut с graphics/libglut на graphics/freeglut, запустите:

Примечание:

Выполняя замену информации о происхождении пакетов, в большинстве случаев также требуется переустановить пакеты, которые зависят от изменившегося пакета. Для принудительной переустановки зависящих пакетов, выполните:

Источник

Kali Linux: модификация пакетов

Продолжаем переводить книгу «Kali Linux Revealed». Девятая глава посвящена расширенному использованию системы. В частности, изучив её, можно узнать о том, как создать из базового дистрибутива Kali именно то, что вам нужно. Сегодня мы публикуем перевод первого раздела этой главы. Речь пойдёт о модификации пакетов Kali.

Глава 9. Расширенное использование системы

Kali создана как модульная настраиваемая среда, ориентированная на цели пентестинга, поддающаяся глубокой настройке и поддерживающая различные сценарии использования. Настройка системы может затрагивать множество уровней. Если нужно — начать можно с исходного кода. Будем считать этот уровень настройки первым. Исходный код пакетов Kali общедоступен. В этой главе мы покажем, как находить пакеты, как их модифицировать и собирать из них собственные пакеты, настроенные так, как нужно именно вам. Модификация ядра Linux — это своеобразная область настройки системы, поэтому ей посвящён отдельный раздел. В нём мы поговорим о том, где найти исходный код ядра, как настроить систему его сборки, и, наконец, как его скомпилировать и собрать необходимые пакеты ядра.

Второй уровень настройки системы заключается в сборке Live-образов. Мы покажем как, используя инструмент live-build , задействовать множество возможностей по тонкой настройке готовых ISO-образов. В том числе, речь пойдёт об использовании предварительно настроенных в соответствии с вашими нуждами пакетов Debian вместо пакетов, доступных на зеркалах.

Кроме того, мы поговорим о том, как создать постоянное хранилище данных для Live-образа, записанного на USB-флэшку. Подобная конфигурация позволяет сохранять файлы и изменения операционной системы между перезагрузками.

9.1. Модификация пакетов Kali

Модификация пакетов Kali обычно является задачей, которую решают участники проекта и разработчики: они обновляют пакеты на новые версии, выпущенные разработчиками этих пакетов, они меняют стандартные конфигурации, которые позволяют лучше интегрировать пакеты в дистрибутив, или исправляют ошибки, о которых сообщили пользователи. Однако, у вас могут быть особые нужды, которым официальные пакеты не соответствуют, поэтому знание того, как собрать модифицированный пакет, может оказаться весьма полезным.

Возможно, вы зададитесь вопросом о том, почему вам вообще нужно этим заниматься. В конце концов, если требуется модифицировать какое-то ПО, вы всегда можете загрузить его исходный код (обычно — с помощью git ), изменить и запустить модифицированную версию. Такой подход позволяет достичь цели, но только тогда, когда это возможно, и когда вы используете для этой цели свою домашнюю директорию. Однако, если приложение нуждается в установке, делающей его доступным во всей системе (например, с использованием make install ), тогда оно замусорит файловую систему файлами, неизвестными dpkg , и скоро станет источником проблем, которые невозможно обнаружить, основываясь на анализе зависимостей пакета. Более того, правильно подготовленные пакеты можно передавать кому-нибудь ещё, их гораздо легче разворачивать на множестве компьютеров, или отменять в них изменения после того, как обнаружилось, что они не дают нужного эффекта.

Итак, когда может понадобится модификация пакетов? Рассмотрим несколько примеров.

Для начала представим, что вы интенсивно используете SET и заметили, что разработчики пакета выпустили новый релиз. Вам срочно нужно его попробовать, а программисты, которые занимаются работой над Kali, заняты участием в конференции. В результате вам придётся обновить пакет самостоятельно.

Вот ещё одна ситуация. Скажем, вам не удаётся заставить работать карту MIFARE NFC и вы хотите пересобрать libfreefare для того, чтобы включить отладочные сообщения и получить некие осмысленные данные, которые можно включить в отчёт об ошибках, который вы готовите.

И, наконец, представим, что программа pyrit вылетает с таинственным сообщением об ошибке. После поиска в интернете вы обнаруживаете коммит в Git-репозитории разработчиков, который, как вам кажется, может исправить эту проблему. Далее, вы собираетесь пересобрать пакет, включив в него найденное исправление.

Мы подробно рассмотрим эти ситуации ниже и постараемся обобщить объяснения таким образом, чтобы вы могли воспользоваться представленными методиками и в других случаях. Однако, надо понимать, что невозможно рассказать обо всём, с чем вы можете столкнуться. Если вы встретились с проблемой, постарайтесь найти решение или обратитесь за помощью на подходящие форумы (подробнее об этом можно почитать в Главе 6, которая рассказывает о том, как искать ответы на сложные вопросы).

Какими бы ни были изменения, которые вы хотите внести в пакет, общая последовательность действий всегда остаётся одной и той же. А именно, нужно загрузить исходный код пакета, распаковать его, внести изменения и собрать пакет. Однако, на каждом из этих шагов обычно можно воспользоваться множеством инструментов, предназначенных для решения одной и той же задачи. Здесь мы отобрали наиболее подходящие и наиболее популярные инструменты, однако, надо отметить, что есть и другие отличные средства, о которых мы здесь не пишем.

9.1.1. Загрузка исходного кода

Пересборка пакета Kali начинается с загрузки исходного кода. Пакет с исходным кодом состоит из множества файлов. Главный файл — это *.dsc (Debian Source Control), он содержит список сопутствующих файлов, среди которых могут быть файлы *.tar. , иногда — файлы *.diff.gz , или *.debian.tar. .

Пакеты с исходным кодом хранятся на зеркалах Kali, работать с которыми можно по HTTP. Вы можете воспользоваться браузером для загрузки необходимых файлов, но самый лёгкий способ решить эту задачу заключается в вызове команды apt source source_package_name . Эта команда требует строки deb-src в файле /etc/apt/sources.list и актуальных индексных файлов (для их обновления можно воспользоваться командой apt update ). По умолчанию в Kali вышеописанные настройки не включены, так как очень немногим пользователям нужен исходный код пакетов, но привести всё в нужное состояние очень просто. Для этого надо добавить строку deb-src в файл /etc/apt/sources.list (сведения об этом можно найти в разделе 8.1.3 «Репозитории Kali», и в разделе 8.1.2. «Подробности о файле sources.list»).

В этом примере мы загружаем пакет с исходным кодом с зеркала Kali. Это — такой же пакет, как и в Debian, так как строка версии не содержит подстроки «kali.». Это означает, что в данный пакет не было внесено каких-либо специфичных для Kali изменений.

Если вам нужна конкретная версия пакета с исходным кодом, которая на момент загрузки недоступна в репозиториях, перечисленных в /etc/apt/sources.list , в таком случае легче всего загрузить её, предварительно выяснив URL её .dsc-файла, найдя его на http://pkg.kali.org и использовав его в команде dget (из пакета devscripts ).

После нахождения URL для пакета с исходным кодом libfreefare , доступного в kali-bleeding-edge , вы можете загрузить его с помощью dget . Сначала будет загружен файл .dsc , после чего он будет разобран для того, чтобы выяснить, на какие ещё файлы он ссылается, затем будут загружены и эти файлы:

Стоит отметить, что dget не выполняет автоматическую распаковку пакетов с исходным кодом, так как он не может проверить PGP-подписи этих пакетов. Таким образом, нам нужно выполнить это вручную, воспользовавшись командой dpkg-source -x dsc-file . Кроме того, вы можете активировать принудительное извлечение пакетов с исходным кодом, применив опцию —allow-unauthenticated или -u . И наоборот, можно воспользоваться опцией —download-only для того, чтобы пропустить шаг распаковки.

▍Загрузка исходного кода из Git

Вы могли обратить внимание на то, что при вызове apt source вам сообщают о возможности использования Git-репозитория для поддержки пакета. Это может быть репозиторий Debian или репозиторий Kali.

Все пакеты, специально подготовленные для Kali, можно обнаружить в Git-репозиториях, расположенных на git.kali.org. Загрузить код из этих репозиториев можно с помощью команды вида git clone git://git.kali.org/packages/source-package . Если при выполнении этой команды то, что нужно, загрузить не удаётся, попробуйте переключиться на ветку kali/master командой git checkout kali/master .

В отличие от того, что можно загрузить с помощью команды apt source , в полученном дереве не будут автоматически применены патчи. Взгляните на debian/patches/ для того, чтобы узнать о возможных изменениях, сделанных в Kali.

Вы можете использовать Git-репозитории как альтернативный способ загрузки исходного кода и, в целом, следовать другим рекомендациям из этого раздела. Но когда разработчики Kali работают с этими репозиториями, они используют другой процесс подготовки пакетов и инструменты из пакета git-buildpackage , о которых мы здесь не рассказываем. Подробности об этих инструментах можно найти здесь.

9.1.2. Установка зависимостей для сборки

Теперь, когда у вас есть исходный код, нужно установить зависимости сборки. Они необходимы для того, чтобы собрать бинарный пакет. Кроме того, весьма вероятно, они пригодятся для частичных сборок, которые вам может понадобиться выполнять для проверки изменений в процессе их внесения в пакет.

В каждом пакете исходного кода зависимости сборки объявлены в поле Build-Depends файла debian/control . Используем apt для установки этих зависимостей (предполагается, что вы находитесь в директории, содержащей распакованный пакет с исходным кодом):

В этом примере все зависимости сборки можно разрешить с помощью пакетов, которые доступны APT. Так может быть не всегда, так как инструменты сборки kali-rolling не проверяют возможность установки зависимостей сборки (во внимание принимаются только зависимости бинарных пакетов). На практике бинарные зависимости и зависимости сборки часто тесно связаны и для большинства пакетов достаточно зависимостей сборки.

9.1.3. Внесение изменений в код пакетов

В этом разделе невозможно рассказать обо всех возможных видах изменений, которые может понадобиться внести в некий пакет. Это потребовало бы освещения всех тонкостей работы с пакетами Debian. Однако, здесь мы расскажем о трёх наиболее распространённых вариантах, упомянутых выше, и опишем некоторые важнейшие шаги процесса модификации пакетов, которых невозможно избежать (воде поддержки в актуальном состоянии файла changelog ).

Первое, что надо сделать, заключается в изменении номера версии пакета. Это нужно для того, чтобы новые пакеты можно было отличить от исходных, присутствующих в Kali или Debian. Для того, чтобы это сделать, мы обычно добавляем суффикс, идентифицирующий того, кто выполняет изменения (обычно это частное лицо или компания). Так, например, мой ник в IRC — buxy , поэтому я буду использовать его как суффикс. Подобное изменение лучше всего производить с помощью команды dch (Debian CHangelog) из пакета devscripts . В моём случае вызов этой команды будет выглядеть как dch —local buxy . Эта команда вызывает текстовой редактор ( sensible-editor , который запускает редактор, указанный в переменной окружения VISUAL или EDITOR , в противном случае вызывается /usr/bin/editor ), который позволяет задокументировать изменения, вносимые в конкретную сборку. В данном случае видно, что команда dch действительно изменила файл debian/changelog :

Если вы выполняете подобные изменения регулярно, возможно, есть смысл внести в переменные окружения DEBFULLNAME и DEBEMAIL , соответственно, ваше полное имя и адрес электронной почты. Эти данные могут быть использованы множеством инструментов для работы с пакетами, включая dch , который внедрил их в строку, начинающуюся с « — » в вышеприведённом коде.

▍9.1.3.1. Применение патчей

В одной из описанных выше ситуаций мы загрузили пакет с исходным кодом pyrit и собираемся применить патч, который нашли в Git-репозитории разработчиков пакета.

Потребность выполнить подобное встречается часто, поэтому сложностей с этим возникнуть не должно. К сожалению, особенности работы с патчами могут различаться, что зависит от формата пакета с исходным кодом, и от того, как именно организована работа с пакетами в репозитории Git (в том случае, если для поддержки пакета используется Git).

▍9.1.3.1.1. Применение патча к распакованному пакету с исходным кодом

Итак, вы выполнили команду apt source pyrit и у вас есть папка pyrit-0.4.0 . В такой ситуации можно применить патч напрямую, воспользовавшись командой patch -p1 :

К этому моменту у вас имеется исходный код, пропатченный вручную, и вы можете собрать бинарный файл модифицированной версии пакета (о сборке мы поговорим ниже, в разделе 9.1.4). Но если вы попытаетесь собрать обновлённый пакет, произойдёт ошибка, в сообщении которой говорится о неожиданных изменениях кода пакета, подготовленного его разработчиками ( unexpected upstream changes ). Это произошло из-за того, что pyrit (как и большинство пакетов с исходным кодом) использует формат исходного кода (взгляните на файл debian/source/format ), известный как 3.0 (quilt), где изменения в коде, вносимые разработчиками пакета, должны быть записаны в отдельных патчах, хранимых в debian/patches/ , при этом файл debian/patches/series указывает на порядок, в котором эти патчи должны быть применены. Вы можете зарегистрировать внесённые изменения в виде нового патча, воспользовавшись командой dpkg-source —commit :

▍Управление патчами с помощью quilt

Соглашение по работе с патчами, о котором идёт речь, стало популярным благодаря инструменту, который называется quilt . Формат пакета исходного кода «3.0 (quilt)», таким образом, совместим с этим инструментом — с небольшим изменением, которое заключается в том, что он использует debian/patches вместо patches . Этот инструмент можно найти в одноимённом пакете. Здесь можно почитать руководство по нему.

Если пакет с исходным кодом использует формат 1.0 или 3.0 (native), тогда требования по регистрации изменений в коде пакетов в виде патчей не выдвигаются. Сведения об изменениях автоматически встраиваются в получившийся пакет с исходным кодом.

▍9.1.3.1.2. Применение патча к коду, полученному из Git-репозитория

Если вы, для загрузки исходного кода, воспользовались Git, то ситуация осложняется. Существует множество способов организации работы с Git и связанных с ними инструментов, и совершенно очевидно то, что далеко не все Debian-пакеты готовят с использованием одних и тех же рабочих процессов и программных средств. Уже обсуждённое различие пакетов, касающееся формата файлов, применимо и здесь, но, работая с Git, необходимо выяснить, применены ли уже патчи в дереве исходного кода, или они лишь хранятся в debian/patches (при таком подходе они применяются в ходе сборки).

В данной ситуации самый популярный пакет — это git-buildpackage . Именно его мы используем для управления репозиториями на git.kali.org. Когда вы используете его, патчи не применяются предварительно в дереве исходного кода, вместо этого они хранятся в debian/patches . Вы можете вручную добавить патчи в эту директорию и внести их список в debian/patches/series , но пользователи git-buildpackage обычно применяют средство gbp pq для редактирования всей последовательности патчей как одной ветки, которую вы можете расширить или перекомпоновать в соответствии со своими потребностями. Посмотрите справку по gbp-pq(1) для того, чтобы разобраться с тем, как это сделать.

Инструмент git-dpm (и команда с тем же именем) — это ещё одно средство для работы с пакетами в Git, с которым вы можете встретиться. Оно записывает метаданные в debian/.git-dpm и поддерживает в актуальном состоянии патчи в дереве исходного кода, используя команду rebase в применении к ветке которую оно собирает из содержимого debian/patches .

▍9.1.3.2. Настройка параметров сборки

Обычно параметры сборки приходится настраивать в тех случаях, когда нужно включить дополнительные функции или особенности поведения пакета, которые не активированы в его официальном варианте. Это бывает нужно и в случаях, когда нужны особые значения параметров, задаваемых во время сборки посредством опции ./configure или с помощью переменных, устанавливаемых в окружении сборки.

В подобных случаях изменения обычно ограничены debian/rules , где задаётся последовательность шагов процесса сборки пакета. В самых простых случаях строки, относящиеся к исходной конфигурации ( ./configure … ), или сами команды сборки ( $(MAKE) … или make … ) найти несложно. Если эти команды не вызываются непосредственно, вероятно, их вызов выполняется через другие команды, вызываемые явно. В подобных случаях стоит обратиться к документации этих команд для того, чтобы узнать о том, как изменить их стандартное поведение. При работе с пакетами, которые используют dh , вам может понадобиться переопределить команды dh_auto_configure или dh_auto_build (посмотрите справку по ним для того, чтобы узнать о том, как это сделать).

Для того, чтобы приблизить эти объяснения к практике, применим их к одному из вышеупомянутых сценариев. А именно, мы собираемся модифицировать libfreefare , передав опцию —enable-debug скрипту ./configure для того, чтобы в результате можно было получить больше сведений от инструментов для работы с NFC и подготовить более качественный отчёт по карте MIFARE NFC, которую не удаётся распознать. Так как пакет, для управления процессом сборки, использует dh , нужно добавить (или, в данном случае, модифицировать) цель override_dh_auto_configure . Вот соответствующее извлечение из файла debian/rules libfreefare :

▍9.1.3.3. Упаковка новой официальной версии пакета

Взглянем на ещё один пример, так как мы говорим об упаковке официальных версий пакетов. Скажем, вы — опытный пользователь SET и заметили, что вышел новый официальный релиз (7.4.5), который пока недоступен в Kali (тут имеется лишь версия 7.4.4). Вам хочется собрать и опробовать обновлённый официальный пакет. Так как произошло лишь небольшое увеличение версии пакета, вы не ожидаете, что изменение потребует каких-либо изменений на уровне упаковки.

Для того, чтобы обновить код, вы извлекаете новый архив рядом с текущим пакетом с исходным кодом и копируете директорию debian из текущего пакета в новый. Затем вы увеличиваете версию в debian/changelog .

Вот и всё. Теперь можно собрать обновлённый пакет.

В зависимости от изменений, внесённых в новую сборку официальной версии, может, кроме того, понадобиться изменить зависимости сборки и зависимости времени выполнения, установить новые файлы. Это — гораздо более сложные операции, которые мы здесь не рассматриваем.

9.1.4. Запуск сборки

Когда в исходный код пакета внесены все необходимые изменения, вы можете приступить к созданию бинарных файлов в формате .deb . Весь этот процесс проходит под управлением команды dpkg-buildpackage и выглядит так:

Опции -us -uc отключают подписи для некоторых из сгенерированных файлов ( .dsc , .changes ), так как эта операция даст сбой если у вас нет ключей GnuPG, связанных с идентификационными данными, помещёнными в файл changelog . Опция -b предназначена для организации процесса сборки, на выходе которого оказываются только бинарные файлы. При таком подходе не создаётся пакет с исходным кодом ( .dsc ), а создаются только бинарные .deb-пакеты. Используйте эту опцию для того, чтобы избежать сбоев на этапе сборки пакетов с исходным кодом: если вы не зарегистрировали соответствующим образом изменения в системе управления патчами, в ходе этой операции могут возникнуть предупреждения и процесс сборки будет прерван.

Как можно узнать из сообщений dpkg-deb , созданные бинарные пакеты теперь доступны в родительской директории (в той, в которой находится директория пакета с исходным кодом). Устанавливают такие пакеты с использованием команды dpkg -i или apt install .

Мы предпочитаем использовать apt install , а не dpkg -i , так как apt позволяет легко справляться с проблемой отсутствующих зависимостей. Правда, не так давно приходилось использовать dpkg , так как команда apt не могла работать с .deb-файлами, которые расположены вне репозиториев.

▍Программы-оболочки для dpkg-buildpackage

Чаще всего Debian-разработчики, для сборки пакетов, используют программы-оболочки вроде debuild . Эта программа, например, запускает dpkg-buildpackage как обычно, но, кроме того, вызывает скрипт ( lintian ), который выполняет множество проверок сгенерированного пакета на соответствие правилам Debian. Этот скрипт, кроме того, очищает окружение, в результате локальные переменные окружения не могут повлиять на процесс сборки пакета. Команда debuild — это один из инструментов, входящих в состав пакета devscripts , инструменты которого, за счёт единообразия, облегчают жизнь тем, кто занимается поддержкой пакетов.

Итоги

В этом материале мы рассказали о том, как загружать исходный код пакетов, модифицировать его и собирать новые .deb-пакеты, соответствующие вашим нуждам. Эти пакеты, после сборки, устанавливают в системе. Подобное требуется в самых разных случаях, среди которых — потребность как можно раньше получить доступ к обновлённому пакету, новая версия которого пока не включена в Kali, а также необходимость настройки пакета в соответствии с некими нестандартными требованиями. В следующий раз поговорим о сборке собственных ядер Linux.

Уважаемые читатели! Сталкивались ли вы с ситуациями, когда вам нужно было модифицировать и самостоятельно собирать пакеты для Linux? Если да — расскажите пожалуйста, зачем вам это было нужно и какими инструментами вы при этом пользовались.

Источник