Как распаковать deb на linux

Обновлено: 04.07.2024

Время от времени появляются новые задачи либо необходимость в решении старых задач новыми способами — тогда возникает потребность в дополнительном программном обеспечении. Что делать, если вам нужна новая программа для Linux? Попробую описать некий алгоритм.

1. Надо понять какое именно решение вам нужно. Для этого можно использовать поисковые системы. Формировать запрос о своей проблеме и выбирать подходящие решения.

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

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

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

1. Находим официальный сайт приложения и пытаемся найти там .deb пакет (У нас Ubuntu Linux — у него пакетная система основана на deb формате). Если такой пакет есть на официальном сайте, то скачиваем его и устанавливаем.

2. Если .deb пакета нет на официальном сайте, то ищем его в поисковой системе (помимо автора, другие люди могли для удобства собрать deb-пакет для приложения). Запрос может выглядеть так: «xneur deb» или «gimp deb».

3. Если нам не повезло и программа настолько редкая, что deb-пакета для нее нет, то смотрим в каком виде она вообще распространяется.

Установка приложения из tar.gz

Часто приложения распространяются в архивах tar.gz. Этот формат не так удобен в Ubuntu, так как это не пакет, а просто архив, в котором могут быть как исходные коды, так и скомпилированные приложения и библиотеки.

Установка из tar.gz:

1. Распаковываем архив в отдельную директорию.

2. Если есть исполняемый файл — запускаем и пользуемся, если нет — читаем раздел «Компиляция».

Установка приложения из SVN

SVN — Subversion. Это система контроля версий кода, в которых хранится исходный код приложений, особенно Open Source.

1. Создаем директорию для нашего приложения.

2. Открываем терминал в директории (cd 'путь/к/директории');

3. Скачиваем исходные коды:

svn co (SVN-адрес)

4. Читаем раздел «Компиляция».

Установка приложения из CVS

CVS — Concurrent Versions System. Это также система контроля версий кода.

1. Создаем директорию для нашего приложения.

2. Открываем терминал в директории (cd 'путь/к/директории');

3. Скачиваем исходные коды:

cvs -z3 -d (CVS-адрес) co ./

4. Читаем раздел «Компиляция».

Установка приложения из RPM

rpm-пакеты не родные для Ubuntu. Существует утилита alien, с помощью которой можно установить как обычные (sudo apt-get install alien). С ее помощью можно переконвертировать rpm-пакет в deb-пакет. Очень проста в использовании:

И в директории с rpm-пакетом появится deb-пакет. А его мы уже без труда установим.

Компиляция

1. Открываем терминал в директории с нашим приложением (cd 'путь/к/директории');

2. Смотрим информацию о конфигурировании приложения:

Смотрим вывод и решаем с какими параметрами надо конфигурировать. Если эта команда выдает ошибку — значит конфигуратора нет. Если конфигуратор присутствует — конфигурируем:

Можно эту команду выполнить без аргументов — будет стандартная конфигурация.

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

3. Компилируем приложение:

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

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

Если приложения требует инсталляции, то выполняем (понадобятся права администратора — вспоминаем команду sudo):

Эта команда скопирует файлы приложения в необходимые системные директории.

5. Пользуемся приложением.

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

В этой статье для начинающих объясняется, как устанавливать deb-пакеты в Ubuntu. Также показано, как впоследствии удалить эти пакеты deb.

Жизнь была бы слишком простой, если бы вы могли найти все приложения в Центре программного обеспечения. Но этого не происходит, к сожалению.

Некоторое программное обеспечение доступно через пакеты DEB. Это архивные файлы с расширением .deb . Вы можете рассматривать файлы .deb как файлы .exe в Windows. Вы дважды щелкаете по файлу .exe, и он запускает процедуру установки в Windows. Deb-пакеты работают практически по схожему принципу .

Вы можете найти эти пакеты DEB в разделе загрузки на сайте поставщика программного обеспечения. Например, если вы хотите установить Google Chrome в Ubuntu, вы можете загрузить пакет DEB для Chrome со своего веб-сайта.

Теперь возникает вопрос, как установить файлы deb? Существует несколько способов установки пакетов DEB в Ubuntu. Я покажу их вам один за другим в этом уроке.

Установка файлов .deb в дистрибутивы Linux на основе Ubuntu и Debian

Вы можете выбрать инструмент GUI или инструмент командной строки для установки пакета deb. Выбор за вами.

Давайте посмотрим, как установить deb файлы.

Способ 1: использование программного центра по умолчанию

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

Видите, это даже проще, чем установка из .exe-файлов в Windows, не так ли?

Способ 2. Использование приложения Gdebi для установки пакетов deb с зависимостями.

Опять же, жизнь была бы намного проще, если бы все прошло гладко. Но это не жизнь, как мы ее знаем.

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

Что происходит, так это то, что программа может зависеть от другого программного обеспечения (библиотек). Когда разработчик готовит пакет DEB для вас, он / она может предположить, что ваша система уже имеет эту часть программного обеспечения в вашей системе.

Но если это не так, и ваша система не имеет необходимых компонентов программного обеспечения, вы столкнетесь с печально известной «ошибкой зависимости».

Центр программного обеспечения не может самостоятельно обрабатывать такие ошибки, поэтому вам придется использовать другой инструмент под названием gdebi.

Он определяет зависимости и пытается установить эти зависимости вместе с установкой файлов .deb.


Лично я предпочитаю gdebi центру программного обеспечения для установки файлов deb. Это легкое приложение, поэтому установка кажется быстрее. Вы можете прочитать подробно об использовании gDebi и сделать его по умолчанию для установки пакетов DEB.

Вы можете установить gdebi из центра программного обеспечения или используя команду ниже:

Способ 3: установить deb файлы в командной строке с помощью dpkg

Если вы хотите установить deb файлы в команде lime, вы можете использовать команду apt или dpkg. Команда Apt на самом деле использует команду dpkg, но apt более популярна и проста в использовании.

Если вы хотите использовать команду dpkg для установки пакетов deb, вот как это сделать:

Если при установке пакетов deb вы получили ошибку зависимости, вы можете использовать следующую команду для устранения проблем зависимости:

Как удалить пакеты deb

Удаление пакета deb не имеет большого значения. И нет, вам не нужен оригинальный файл deb, который вы использовали для установки программы.

Способ 1: удаление пакетов deb с помощью команд apt

Все, что вам нужно, это имя программы, которую вы установили, и затем вы можете использовать apt или dpkg, чтобы удалить эту программу. Для этого введите вот эту команду, где program_name название программы, которую вы хотите удалить.

Теперь возникает вопрос, как найти точное имя программы, которое нужно использовать в команде удаления? У команды apt есть решение и для этого.

Например, я установил приложение AppGrid в предыдущем разделе, и если я хочу узнать точное имя программы, то к предыдущей команде добавляю разделитель | , затем grep grid , где grid является частью имени команды.

Команда grep удалит из вывода все строки, в которых нет слова grid и мы получим только то, что нас интересует. То есть в данном случае вместо большого списка будет только та строка, которая интересует. Это намного проще, чем искать глазами, правда?

Как видите, установлена ​​программа appgrid. Теперь вы можете использовать это имя программы с командой apt remove.

Способ 2: удалить пакеты deb с помощью команд dpkg

Вы также можете использовать dpkg, чтобы найти имя установленной программы:

Вывод выдаст все установленные пакеты, которые содержат слово grid:

ii в приведенной выше команде вывод означает, что пакет был правильно установлен.

Теперь, когда у вас есть имя программы, вы можете использовать команду dpkg, чтобы удалить ее:

Я надеюсь, что это руководство для начинающих помогло вам установить deb файлы в Ubuntu. Я добавил часть удаления, чтобы вы могли лучше контролировать установленные вами программы.

Более подробно о deb-пакетах вы можете почитать на официальном сайте Debian тут.

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

В репозитариях Ubuntu собрано огромное количество программ и библиотек. На сайтах самих программ достаточно часто встречаются deb-пакеты, которые можно скачать и установить. Однако все же бывает ситуация, когда нужного ПО нет в репозитариях или на сайте нельзя скачать пакет для Ubuntu, или, наконец, в репозитарии есть старая версия, но она вас не устраивает тем, что в ней присутствует досадный баг или нет нужной функциональности.


Не спешите качать исходники и делать ./configure && make && make install. Это приведет к тому что у вас возникнет каша из библиотек и софта, установленного вручную и через apt, управляться с которой станет очень тяжело. Гораздо лучше потратить побольше времени и приготовить deb-пакет, который уже потом установить используя apt. Преимущества же apt над ручной установкой очевидны.

Допустим мы находимся в ситуации, когда в следующей версии Ubuntu или Debian есть необходимая нам программа, а в текущей версии в репозитории ее нет.

Например, у меня на рабочем компьютере установлена Ubuntu 7.10 Gutsy и мне хочется установить программу Guake. В репозиториях Gutsy ее нет. На сайте deb-пакета под мою версию Ubuntu нет, потому придется делать его самому.

Для бэкпортирования или сборки из исходников нам понадобятся определенные утилиты. Перед началом работы установим минимальный набор, который будет необходим для этого. Это пакеты debhelper, dh-make, devscripts, fakeroot, build-essential, automake, gnupg, lintia. Отмечу что для пакетирования конкретного софта будут требоваться дополнительные комплияторы, dev-версии библиотек, которые видимо лучше устанавливать когда они понадобятся.

После установки софта мы готовы к бэкпортированию guake.

Подготовим директорию в которой будем работать:
konstantin@konstantin-desktop:

$ mkdir -p /tmp/dev/deb/guake
konstantin@konstantin-desktop:

Backported from Interpid

guake (0.3.1-5ubuntu1) gutsy; urgency=low

* Backported from Interpid

-- Konstantin Mikhaylov <konstantin@konstantin-desktop> Thu, 18 Sep 2008 15:07:30 +1100

Скорее всего собрать пакет сходу не удастся из-за отсутствия некоторых библиотек. У меня так и вышло:
konstantin@konstantin-desktop:/tmp/dev/guake/guake-0.3.1$ dpkg-buildpackage -rfakeroot
dpkg-buildpackage: source package is guake
dpkg-buildpackage: source version is 0.3.1-5ubuntu1
dpkg-buildpackage: source changed by Konstantin Mikhaylov <konstantin@konstantin-desktop>
dpkg-buildpackage: host architecture i386
dpkg-buildpackage: source version without epoch 0.3.1-5ubuntu1
dpkg-checkbuilddeps: Unmet build dependencies: autoconf libgtk2.0-dev intltool python-gtk2-dev
dpkg-buildpackage: Build dependencies/conflicts unsatisfied; aborting.
dpkg-buildpackage: (Use -d flag to override.)

Чтобы начать создавать deb пакеты, нужно установить несколько пакетов:

Подготовка папки с исходниками

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

Папка должна называться имяпакета-версия. Т.е. если у меня есть папка Plugins с программой версии 0.1, то я создаю папку с именем plugins-0.1.


Теперь нужно создать архив с этой папкой. Архив должен содержать в имени *.orig.tar.gz, т.е.:


Последний подготовительный шаг, это создание в папке с исходниками папки debian со множеством служебных файлов. Чтобы это сделать, нужно выполнить команду:


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

На самом деле документация говорит, выбирать вариант только single. Т.к. я не смог понять всех требований к пакету типа library но меня вполне устраивает результат, то описание и дальше пойдет про пакет типа library.

Настройка пакета

Вся настройка пакета происходит путем редактирования файлов в каталоге debian. Рассмотрим те файлы, которые будем использовать:

  • changelog — история пакета.
  • control — главный конфиг пакета;
  • rules — аналог Makefile для пакета;

changelog

Данный файл содержит историю изменения пакета и текущую версию пакета. Посмотрим на его содержимое:


В начале идет название пакета — libvksplugins, затем его версия. Версия делиться на две части символом «-». Первая часть показывает версию программы в пакете, вторая «ревизию» пакета. Ревизия это версия пакета, т.е. если раньше такого пакета не было, то ревизия равна 1. Если же пакет с такой версией программы уже был, но в нем произошли изменения, то ревизия увеличивается.

Слово unstable показывает, что пакет является не стабильным, т.е. он не был протестирован должным образом на машинах пользователей.

Надпись urgency=low показывает срочность изменения. Т.к. срочности нет, то значение равно low. Если бы, мы делали пакет для исправления серьезной уязвимости или ошибки, то значение можно было бы установить в high.

После первой строки идет пустая строка, а за ней первая запись:


В Debian, changelog используется для автоматического закрытия ошибок в системах отслеживания ошибок в программных продуктах. Т.к. в данном случае, я не использую такую систему, то эта строка принимает вид:

Последняя строка является подписью человека, сделавшего запись. В ней содержится имя и адрес, а также дата изменения.

После установки deb пакета, файл changelog устанавливается в

control

Файл debian/control является главным конфигом, при создании deb пакета. Вот пример такого файла:


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

Source Данная секция говорит о том, что нужно создать пакет исходных кодов. Параметром указано libvksplugins, это значит, что пакет исходных кодов будет называться libvksplugins.

Priority Эта секция устанавливает приоритет пакета. Т.к. система может прекрасно обойтись без нового пакета, то значение секции установлено в optional. Т.е. этот пакет не обязателен для установки. Подробнее о приоритетах написано здесь.

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

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

Видно, что в зависимостях стоят debhelper (>= 9), cmake. Зависимость debhelper (>= 9) ставиться для всех пакетов по умолчанию. Она нужна для корректной работы программ вида dh_*.

Второй элемент cmake был добавлен потому, что папка с исходниками содержала файл CMakeLists.txt, т.е. для сборки используется система сборки CMake. Для того, чтобы узнать, какие зависимости есть у программы, можно почитать ее документацию. Кроме этого, можно воспользоваться командой dpkg-depcheck. Данная команда должна запускаться так:


Но, т.к. при использовании CMake нет скрипта конфигурирования, то я использую ее так:


Из примечательных тут можно отметить:

cmake
qt4-qmake
libqt4-dev

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


При этом в CMakeLists.txt указана версия cmake, которую нужно использовать:


Я думаю, что разработчику виднее, и поэтому указываю версию из CMakeLists.txt. Для Qt 4 все понятно с номерами версий, но для очистки совести проверим и их версии:


Т.е. для Qt 4 указываем версию 4.8.6:


Standards-Version Версия стандарта, в соответствии с которым создан файл. Это значение не нужно менять.

Section. Секция для пакета, т.е. группа пакетов, выполняющая одну задачу. В Политике Debian разделе 2.4 этот вопрос описан более подробно.

Homepage Домашняя страница проекта. Т.к. данный код писал я и у него нет страницы, просто удаляю эту строку.

Vcs-* Ссылки на репозитории проекта. Их у меня тоже нет, поэтому удаляю эти строки.

Другие пакеты После секции файла, где описывается пакет с исходниками, идут секции, которые описывают другие пакеты, создаваемые из пакета с исходниками. Схема создания пакетов:


Из схемы видно, что из исходников программы, я хочу получить 4 пакета:

  • пакет с исходными кодами;
  • пакет с бинарником (самой библиотекой);
  • пакет для разработки (заголовочные файлы);
  • пакет с документацией.

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

Кроме описанных выше пакетов, можно создать dbg пакет с отладочной сборкой программы. Это может пригодиться, если программа падает и у Вас есть под рукой отладчик. Однако, я так и не смог понять как это делать. Документация не дает ответа на этот вопрос. Если делать так как описано в ней, то я либо получаю пустой пакет либо получаю кучу ошибок при сборке.

Схема на рисунке выше показывает, что пакет с исходниками называется libvksplugins_source, однако, в файле control указано, что пакет с исходниками будет называться libvksplugins. На самом деле, он действительно будет называться libvksplugins, а пакет с бинарниками, будет называться libvksplugins… deb. Суть этой путаницы в том, что пакет с исходниками представляет собой tar архив и служебные файлы, тогда как пакет бинарников это архив с расширение deb.

Настройка пакета библиотеки Посмотрим внимательно на описание пакета библиотеки:

Для пакетов, содержащих скрипты или тексты, нужно указывать значение как all.

Третья строка, описывает зависимости создаваемого пакета. Вот как она описана в 4й главе Руководства начинающего разработчика Debian:

Утилита dh_shlibdeps вычисляет зависимости двоичного пакета от общих библиотек. Она генерирует список исполняемых файлов ELF и общих библиотек, которые находит для каждого двоичного пакета. Этот список подставляется вместо $ .

Утилита dh_perl вычисляет зависимости Perl. Она генерирует список зависимостей от perl или perlapi для каждого двоичного пакета. Этот список подставляется вместо $ .

Некоторые команды пакета debhelper могут добавлять зависимости к вашему генерируемому пакету. Каждая команда генерирует список необходимых пакетов для каждого двоичного пакета. Этот список подставляется вместо
$ .

Утилита dh_gencontrol генерирует файл DEBIAN/control для каждого двоичного пакета, заменяя $ , $ , $ и т.д на полученные значения.

Т.е. эта строка говорит о том, что сборщик пакета сам определит зависимости.

Последний раздел данной секции это описание пакета. Первая строка содержит кратное описание, последующие строки содержат более подробное описание. Подробное описание, должно иметь определенный формат:

  • строка должна начинаться с пробела;
  • строка не должна быть длиннее 80 символов;
  • пустая строка должна начинаться с пробела и состоять из символа точки.

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

rules

Данный файл является аналогом Makefile для сборки пакетов. По умолчанию, он создается в таком виде:


Видно, что это bash скрипт с синтаксисом Makefile. Единственная интересная конструкция здесь это


Это шаблон, который для всех целей вызывает dh команду с передачей аргументов ей. Для сборки пакета важно, чтобы текст dh $@ начитался с символа табуляции. Т.е. отступ это не пробелы, а табуляция.

Т.к. исходники используют систему сборки CMake, то нужно изменить эту запись следующим образом:

Содержимое пакетов

После того, как мы указали в debian/control какие пакеты мы хотим получить, нужно указать какие файлы в какой пакет помещать. Для этого, для каждого названия пакета из файла control, нужно создать в папке debian два файла. Первый должен называться пакет.dirs, а второй пакет.install. Суть файлов в том, что первый указывает, какие папки нужно создать для пакета, а второй, какие файлы включить в пакет.

Посмотрим на их содержимое:


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

Завершение настройки

Т.к. исходники мои, то никаких дополнительных описаний и ограничений copyright у меня нет, поэтому я удаляю все лишние файлы из каталога debian.

Сборка пакетов

После настройки, сборка пакетов происходит довольно просто, нужно в папке проекта (которая включает подпапку debian) выполнить команду:


Параметры -us -uc говорят о том, что не нужно подписывать gpg ключом созданные пакеты. Их можно не использовать, если настроен ключ подписи gpg по умолчанию. Как указать ключ подписи по умолчанию, я тоже не понял. Если все прошло хорошо, то у нас поваляется набор пакетов в папке выше:

Заключение

Если вы дочитали до сюда — значит вы любите читать.

Этот текст является результатом моего опыта внедрения deb пакетов на работе. Опыт показал, что наличие сетевого репозитория (reprepro) и внимательное отслеживание версий, позволяют без проблем обновлять и тестировать различные версии ПО на парке из 30 машин с системами Astra Linux 1.3, 1.4 и Эльбрус ОС.

Читайте также: