Менеджер пакетов для kali linux

Статья Расширенный пакет управления в Кали Linux

Огромное спасибо пользователю persivald за своевременный перевод!

Расширенный пакет управления в Kali Linux

Advanced Package Tool (APT) — это когда программы, библиотеки, документация и даже ядро установлены и настроены для работы на Kali и других Debian-подобных дистрибутивах. АРТ работает настолько хорошо, что большинство пользователей часто не замечают его присутствия, за исключением поиска некоторых программ и (надеюсь) обноволений для их системы.

Для большинства стандартных пользователей использующих АРТ таким образом (имеется ввиду установил и забыл пр.переводчика) это вполне приемлемо, но нам хочется думать, что люди использующие Kali Linux не стандартные пользователи (в хорошем смысле) поэтому мы публикуем этот пост, что бы рассказать Вам о возможностях его использования и как получить приемущества всей экосистемы доступных пакетов, сохраняя при этом стабильность Вашей Kali.

Большинство людей скажут Вам, что Вы не должны надеяться на пекетный менеджер, а напротив, компилировать всё из источника, потому что таким образом Вы будете лучше понимать систему. Частично это так, Вы многое изучите и поймёте, особенно если начнёте настройку вручную, но это довольно быстро надоедает и отнимает на мало времени, которое Вы могли бы потратить на hacking или изучение чего-нибудь нового, желательно одновременно.

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

Добавление источников пакетов в Kali Linux

Если вы хотите сделать свое будущее счастливым, вы не должны напрямую редактировать /etc/apt/sources.list . Для каждого нового репозитория пакетов, который вы добавляете в свою систему, создайте новый файл с описательным именем (например, debian-unstable.list) в /etc/apt/sources.list.d/. Если оставить исходный файл sources.list нетронутым, если Kali необходимо его обновить, он не будет прерывать вас во время обновления, спрашивая, какую версию файла сохранить.В этом посте мы добавим репозиторий Kali Bleeding-Edge и нестабильные и экспериментальные репозитории Debian.

Репозиторий kali-bleeding-edge содержит ряд инструментов, которые очень популярны и меняются очень часто (даже ежедневно). Было бы непрактичным и трудоемким вручную создавать и тестировать обновленные пакеты, чтобы пакеты в этом репозитории генерировались автоматически всякий раз, когда изменяется исходный источник. С одной стороны, это означает, что обновления Ваших пакетов не старше 24х часов, но с другой стороны, эти пакеты не тестируются, поэтому вам нужно осознавать, что пакеты в этом репозитории могут время от времени ломаться.
Вы можете добавить репозиторий и обновить список доступных пакетов следующим образом.

Нестабильные и экспериментальные хранилища Debian

Kali Linux является производным от Debian Testing, у которого есть более современное программное обеспечение, чем в Debian Stable. Для еще более позднего программного обеспечения существует дистрибутив Debian Unstable, который является rolling версией Debian, содержащей самые последние пакеты. Когда вы сталкиваетесь с ошибкой в пакете Debian, в репозитории Debian Unstable уже может лежать исправленая версия, поэтому рекомендуется добавить ее в вашу систему Kali. Как и в случае с kali-bleeding-edge, пакеты в Unstable могут время от времени ломаться.

Debian Experimental — еще один репозиторий, содержащий пакеты, которые находятся в разработке. Пакеты в этом репозитории всегда обновляются, но при этом могут быть очень глючными, даже хуже, чем в kali-bleeding-edge или Debian Unstable. APT будет устанавливать пакеты только из этого репозитория, если вы явно запросите их, и вы всегда можете всегда откатиться, если что-то перестанет работать.

Определение приоритетов пакетов

Чтобы определить, какие пакеты будут установлены, APT умеет назначать приоритеты для всех источников пакетов, отдавая предпочтение наивысшему приоритету. Пакет с приоритетом 0 никогда не будет установлен, а пакет с приоритетом более 1000 будет всегда установлен, даже если это откат пакета на старую версию.

Это прекрасно для APT, но как пользователь сможет увидеть, какой приоритет назаначен конкретному пакету? Введите малоизвестную команду «apt-cache» и ее опцию «policy», которая покажет все ваши настроенные репозитории и их назначенные приоритеты.

Настройка распределения по умолчанию

Теперь, когда вы добавили допольнительные репозитории в вашу систему, вы захотите начать изучение и установку новых пакетов, но прежде чем вы это сделаете, неплохо сообщить APT, что ваш дистрибутив по умолчанию, который для пользователей Kali Linux — это «kali -rolling». Таким образом, ваша система не будет обновляться из какого-либо другого дистрибутива без вашего согласия. Настройте свой дистрибутив по умолчанию, добавив «APT :: Default-Release» kali-roll «;» в /etc/apt/apt.conf.d/local.

Если вы назначили свой дистрибутив по умолчанию, каждый раз, когда вы запускаете «apt full-upgrade», он будет применять обновление для kali-rolling, что поможет поддерживать стабильность вашей системы.

Запрос сокращения обновления

Если вы используетесь каким-либо Debian-подобным дистрибутивом достаточно давно, то при запуске «apt upgrade» вы сталкиваетесь с запросом о файле конфигурации и хотите ли вы сохранить локальную версию, использовать новую версию или сравнить ее. Чаще всего вы принимаете дефолт, лишь отвлекаясь на эти запросы.

Можно избежать этих запросов, обновив файл /etc/apt/apt.conf.d/local с помощью параметров «DPkg :: options» («-force-confdef»; «-force-confold»; >’ как показано ниже. Эта строка сообщает APT действовать самостоятельно: если файлы не изменились (-force-confdef), а если файлы разные, то можно сохранить существующую версию (-force-confold).

Закрепление версии пакетов

Иногда вы обнаруживаете одно из приложений, которое нуждается в определенной версии конкретного пакета и не будет работать с каким-либо другим. В некоторых случаях обновление одного пакета может негативно сказаться на других инструментах. Это произошло недавно с обновлением пакета devscripts, что мешало нам создавать пакеты Kali.

К счастью, APT позволяет привязать пакет к определенной версии, установив приоритет 1001 в / etc / apt / preferences. Например, чтобы сообщить APT, чтобы пакет devscripts содержал версию 2.16.x, вы должны добавить следующее:

В этой статье мы лишь поверхностно коснулись того, как вы можете расширить APT далеко за пределы стандартной экосистемы Kali или Debian. Алгоритмы АРТ очень эффективны, и проблемы в них встречаются редко, поэтому вам не нужно бояться пробовать другие репозитории. Чтобы узнать больше об APT и о том, как настроить его по своему желанию, мы рекомендуем обратиться к Kali Linux Revealed и The Debian Administrator’s Handbook, в которых содержится множество информации, советов и трюков.

Источник

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? Если да — расскажите пожалуйста, зачем вам это было нужно и какими инструментами вы при этом пользовались.

Источник