Меню Рубрики

Установка всех зависимостей автоматически

Неудовлетворенные зависимости Ubuntu

При установке пакетов из официальных или сторонних репозиториев вы можете столкнуться с проблемой неудовлетворенные зависимости Ubuntu. Чтобы понять причину возникновения этой ошибки сначала надо разобраться как работают пакетные менеджеры в Linux. Здесь всё компоненты системы, библиотеки и сами программы разделены на пакеты. И если какой-либо программе нужна определенная библиотека, она не поставляется вместе с этой библиотекой, а ожидает, что эта библиотека будет уже установлена в системе.

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

Неудовлетворенные зависимости в Ubuntu

По английски наша ошибка ещё может писаться как the following packages have unmet dependencies. Она может возникнуть в нескольких случаях, давайте сначала рассмотрим основные из них:

  • Вы используете dpkg для установки deb пакета. Эта утилита не занимается установкой зависимостей. Вместо неё надо использовать apt install или потом просто установить недостающие зависимости с помощью apt, как это делается описано ниже;
  • Вы используете старую версию дистрибутива — в старых версиях могло что-то изменится в репозитории и часть пакетов была удалена или переименована. С LTS версиями такое случается редко, но с обычными релизами вполне может произойти;
  • Вы пытаетесь установить программу не от своего дистрибутива — несмотря на родство всех дистрибутивов семейства Debian, не желательно использовать программы из других дистрибутивов, так, как они могут требовать пакеты, которые в этом дистрибутиве называются по другому;
  • У вас установлен устаревший пакет, который не позволяет обновить некоторые зависимости — случается, когда в системе уже есть какой-нибудь пакет старый пакет, требующий старую версию библиотеки, а новая программа, которую вы собираетесь установить уже хочет более новую версию и не позволяет её обновить. Эта проблема не очень типична для Ubuntu, так как здесь большинство версий программ в репозиториях заморожено, но часто встречается при использовании дистрибутивов с системой роллинг релизов.

1. Обновление и исправление зависимостей

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

Эта команда установит зависимости, которые есть во официальных репозиториях (поможет при использовании dpkg) и если это не решит проблему, то удалит пакеты, для которых зависимости удовлетворить не удалось. Также после этого можно выполнить:

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

sudo apt upgrade
sudo apt full-upgrade

Если причиной вашей проблемы стал устаревший пакет надо его удалить или придумать для него замену. Например, если у вас установлена старая версия php, могут возникнуть проблемы с установкой новой версии, потому что будут конфликтовать версии библиотек, от которых зависит программа. Однако можно найти PPA со специально подготовленной старой версией php, которая ни с кем конфликтовать не будет.

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

2. Установка зависимостей

Дальше установка зависимостей Ubuntu. Следующий этап, если вы скачали пакет в интернете, например, от другого дистрибутива с таким же пакетным менеджером, можно попытаться установить таким же способом библиотеки, которые он просит. Это может сработать особенно, если вы пытаетесь установить программу из старой версии дистрибутива. Пакеты можно искать прямо в google или на сайте pkgs.org:

Здесь собрано огромное количество пакетов от различных дистрибутивов, в том числе и от Ubuntu и Debian. Просто выберите нужную версию пакета для вашей архитектуры. Скачать файл можно чуть ниже на странице пакета:

После загрузки пакета с сайта его можно установить через тот же dpkg:

sudo dpkg -i ffmpegthumbs_19.04.3-0ubuntu1

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

3. Удаление зависимостей

Если у вас есть скачанный пакет, и он говорит, что он зависит о версии библиотеки, которой в вашей системе нет, но вы уверены, что ему подойдет и другая версия, то можно просто убрать эту зависимость из пакета. Но для этого надо его перепаковать. Такая ситуация была когда-то с популярным менеджером Viber. Рассмотрим на примере того же вайбера.

Сначала распакуйте пакет в подпапку package командой:

dpkg-deb -x ./viber.deb package

Затем туда же извлеките метаданные пакета:

dpkg-deb —control viber.deb package/DEBIAN

В файле package/DEBIAN есть строчка Depends, где перечислены все библиотеки, от которых зависит пакет и их версии. Просто удалите проблемную библиотеку или измените её версию на ту, которая есть в системе.

Затем останется только собрать пакет обратно:

И можете устанавливать, теперь с зависимостями будет всё верно:

Но такое исправление зависимостей Ubuntu следует использовать только для пакетов, которые точно неверно собраны. Важно понимать, что пакетный менеджер вам не враг, а помощник, и то что вы отключите зависимости и установите программу ещё не значит, что она потом будет работать.

4. Распаковать пакет

Следующий способ подойдет, если программа которую вы устанавливаете это библиотека, например, веб-драйвер для Selenium. Пакет можно распаковать и просто разложить исполняемые файлы из него по файловой системе в соответствии с папками внутри архива. Только желательно использовать не корневую файловую систему, а каталог /usr/local/ он как раз создан для этих целей.

5. Использовать snap пакеты

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

Выводы

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

источник

Установка пакетов Ubuntu

Установка новых программ — один из самых важных моментов при работе с вашей системой. Раньше мы уже рассматривали добавление PPA в систему и установку программ из исходников. Но даже в PPA есть далеко не все пакеты, а установка из исходников слишком сложна для новичков.

Нередко возникает необходимость поставить программу, для которой уже есть собранные deb пакеты в интернете. Это может быть какая-нибудь не очень популярная программа или даже драйвера, которые вы скачали и хотите установить на компьютер где нет сети. На компьютере без сети установка программ с флешки ubuntu может стать единственным решением. В этой статье будет рассмотрена установка deb пакетов в ubuntu. Мы рассмотрим где их взять и как установить deb в ubuntu.

Где взять deb пакеты?

Ответ прост — на просторах интернета. Если это нужная вам программа, то вы уже знаете где взять для ее пакет. В случае с драйверами ситуация немного сложнее. Все программы и драйвера, которые находятся в официальных репозиториях Ubuntu вы можете найти на сайте launchpad.net, это очень удобно, если на машине, где они должны быть установлены нет интернета. Например, ищем linux-firmware и открываем ее страницу на Launchpad, внизу выбираем версию программы:

Дальше выбираем архитектуру:

И осталось получить deb файл для нашей системы:

Если у вас есть другой компьютер с интернетом или вы планируете устанавливать программы потом, а сейчас нужно только скачать deb пакеты, то это можно сделать с помощью apt:

Пакет будет сохранен в текущей папке и дальше вы сможете все без проблем установить. Но будет скачан только сам пакет, без его зависимостей. Зависимости мы можем получить только в системе с интернетом используя команду apt-rdepends:

apt download имя_пакета $(apt-rdepends имя_пакета|grep -v «^ «)

Теперь у вас есть не только пакет, но и все его зависимости.

Установка deb пакетов Ubuntu

Установить Deb пакет Ubuntu не так уж сложно, для этого даже есть несколько утилит. Можно устанавливать как с помощью графического интерфейса, так и в терминале.

Самый простой способ установки — в графическом интерфейсе, с помощью центра приложений, с него и начнем. Откройте файловый менеджер в папке с пакетом:

Читайте также:  Установка распредвала на авенсис

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

Установка программ Ubuntu с помощью центра приложений мне не очень нравится, он обычно очень долго думает и не всегда правильно открывает программу, но можно воспользоваться другой графической утилитой — gdebi. Сначала ее нужно установить:

sudo apt-get install gdebi

Теперь кликаем правой кнопкой мыши по файлу, выбираем открыть с помощью и gdebi:

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

Установка deb из консоли Ubuntu выполняется не намного сложнее. Для этого используется утилита dpkg. Сначала переходим в папку куда был загружен deb пакет:

sudo dpkg -i имя_пакета.deb

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

Программа не умеет разрешать зависимости, даже если есть доступ к сети, она только устанавливает пакет, поэтому для установки зависимостей после установки deb ubuntu выполните:

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

Это не единственный способ установки пакетов ubuntu через терминал, утилиту gdebi тоже можно запустить таким способом:

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

sudo apt install ./имя_пакета.deb

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

Выводы

Вот и все. Теперь установка deb пакетов в Ubuntu не вызовет у вас проблем. Оказывается, есть несколько способов установки программ в ubuntu и все они имеют свои преимущества. Если у вас остались вопросы, спрашивайте в комментариях!

источник

При установке пакетов лучше указывать только главный пакет или все его зависимости?

У многих программ в Linux имеются зависимости.

Зависимости — это программы и библиотеки, которые необходимы для работы устанавливаемой программы. Причём менеджеры пакетов Linux весьма интеллектуальны и при установке нужного вам пакета, они также автоматически установят все зависимости.

К примеру, я хочу установить Double Commander. Кстати, настоятельно рекомендую эту программу как на Linux, так и на Windows.

Double Commander — это свободный, с открытым исходным кодом, кроссплатформенный файловый менеджер с двумя панелями. Целью данного проекта является создание файлового менеджера, аналогичного по функциональности Total Commander и совместимого с его плагинами.

Так вот, установка Double Commander выполняется командой:

При этом у пакета doublecmd-gtk есть зависимости, это doublecmd-common и doublecmd-plugins:

То есть зависимости также будут установлены.

Но изначально можно было бы запустить команду следующим образом:

То есть мы явно указываем на 3 пакета, которые мы хотим установить.

Результат при обоих способах установки одинаковый — будут установлены 3 пакета и Double Commander будет прекрасно работать. Означает ли это, что между этими двумя вариантами нет разницы?

На самом деле разница есть. В Linux установленные пакеты делятся и маркируются на 2 группы:

  • установленные явно
  • установленные в качестве зависимостей

Это никак не влияет на их работу.

Но, предположим, мы теперь хотим удалить Double Commander:

Обратите внимание на строки:

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

Но если бы при установке мы указали сразу все три пакета, то все они считались бы установленными явно! Это означает, что зависимости не были бы автоматически удалены после удаления основного пакета — теперь их нужно удалять вручную.

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

Если вам хочется ещё больше углубиться в эту тему и понять, как именно удаётся соблюдать все зависимости для такого огромного количества программ Linux, то рекомендуется продолжить чтение в статье «Структура APT пакета: разбираемся в строении пакета Debian».

источник

Как собрать бинарный deb пакет: подробное HowTo

Сегодня я расскажу на абстрактном примере как правильно создать *.deb пакет для Ubuntu/Debian. Пакет мы будем делать бинарный. Пакеты, компилирующие бинарники из исходников здесь не рассматриваются: осилив изложенные ниже знания, в дальнейшем по готовым примерам можно понять суть и действовать по аналогии 🙂

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

В качестве бонуса в конце статьи будет пример быстрого создания собственного локального репозитория: установка пакетов из репозитория позволяет автоматически отслеживать зависимости, и конечно же! — устанавливать всё одной консольной командой на нескольких машинах 🙂

Для тех, кто не хочет вдаваться в мощную систему установки софта в Linux, рекомендую посетить сайт проги CheckInstall: она автоматически создаёт deb-пакет из команды «make install» 😉 А мы вместе с любопытными —

Источники

Информация надёргана из многих мест, но вот два основных:

  • Opennet:L Введение в создание пакетов для дистрибутива GNU Debian/Linux
  • Debian.org: Debian Policy Manual — официальная
  • Ubuntu Wiki: PackagingGuide/Basic

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

Подготовка

Зачем это всё?

Да, CheckInstall умеет создавать рабочий пакет, но он не поддерживает все вкусности, на которые способны deb пакеты 🙂 А именно:

  • Скрипты, выполняющиеся до, после и вместо установки пакета 🙂
  • Автоматическое управление конфигурационными файлами: пакет не позволит затереть старые конфиги новыми без спроса
  • Работа с шаблонами: возможность задавать пользователю вопросы при установке (. )
  • Изменение файлов других пакетов
Что потребуется

Конечно, для создания полноценного пакета хватит архиваторов tar, gz, ar, но можно исключить лишнюю возню, и воспользоваться инструментами, созданными для облегчения жизни 🙂
Ставим:
$ sudo apt-get install dpkg debconf debhelper lintian

Что мы будем делать

Для примера будет рассмотрен некий скрипт /usr/bin/super.sh. Не важно что внутри, главное — как он появится на правильном месте 🙂

Подготовка папки

/supersh . Далее будем называть её корень пакета.
В корне пакета создаём папку «DEBIAN» (заглавными буквами, это важно!). Эта папка содержит управляющую генерацией пакета информацию, и не копируется на диск при установке пакета.
Также корневая папка пакета содержит будущий «корень диска»: при установке пакета все файлы (кроме папки «debian») распаковываются в корень /. поэтому наш скрипт должен лежать по такому пути, относительно корня пакета: «usr/bin/super.sh»
Белым по чёрному:
mkdir -p

/supersh/DEBIAN # управляющая папка
mkdir -p

/supersh/usr/bin # путь к скрипту
cp super.sh

/supersh/usr/bin/ # копируем наш скрипт в нужное место
В итоге имеем:
supersh/DEBIAN/
supersh/usr/
supersh/usr/bin/
supersh/usr/bin/super.sh

Создание пакета: DEBIAN/*

Как я уже сказал, папка DEBIAN содержит файлы, используемые при установке. Здесь я опишу (с примерами) каждый файл.
Для создания полноценного пакета достаточно контрольного файла «control», все остальные используются либо для прикрепления текстовой информации (changelog, лицензия), либо для управления расширенными возможностями установки приложений.
Из описанных ниже файлов в папке DEBIAN/* выбираем необходимые, и заполняем согласно инструкции 🙂
В наше примере реально используется только обязательный DEBIAN/control.

DEBIAN/control: Основная информация

control — центральный файл пакета, описывающего все основные свойства. Файл — текстовый, состоящий из пар «Атрибут: значение». Можно использовать комментарии: символ «#» в начале строки (возможность была добавлена в версии dpkg >= 1.10.11, надеяться на комментарии не стоит :).
В таблице приведены все поля, определённые для контрольного файла. Обязательные поля выделены жирным: без них пакет не будет считаться составленным верно.

Атрибут Описание Примеры
— основные —
Package: Имя пакета: [a-zA-Z0-9-] — только латиница, цифры, и дефис. Имя используется при установке: apt-get install

Package: supersh
Version: Версия пакета (и проги внутри). Используется для определения «обновлять ли».
Формат принят такой: — .
Рекомендую всегда указывать версию пакета: при изменении структуры пакета цифра увеличивается на единичку.
Допустимые символы достаточно вольные: можно использовать дату и буквы. Примеры смотрите сегодня в своём репозитории 🙂
Version: 1.0-1
Version: 2009.12.12-1
Provides Имя приложения (возможно, виртуальное), регистрируемое в системе в результате установки этого пакета.
Используется редко: в основном, если нужно изменить имя пакета, или если более одного пакета предлагают одинаковый функционал. Например, пакеты Apache и nginx предоставляют возможность демона httpd: Provides: httpd
Вы наверняка сталкивались с ошибкой при попытке установки: «is a virtual package». Это оно и есть 🙂
Provides: supersh
Maintainer Имя и почта мэйнтейнера пакета: человека, который «дебианизировал» приложение.
Формат произвольный, но принято имя
Maintainer: o_O Tync
Architecture Архитектура процессора, для которой предназначен пакет.
Допустимые значения: i386, amd64, all, source
all используется для скриптов: они же портативные, верно? 🙂
source используется для компилируемых пакетов с исходниками
Architecture: all
Section Определяет задачу, для которой приложение обычно используется (группа приложений).
Возможные значения: admin, base, comm, contrib, devel, doc, editors, electronics, embedded, games, gnome, graphics, hamradio, interpreters, kde, libs, libdevel, mail, math, misc, net, news, non-free, oldlibs, otherosfs, perl, python, science, shells, sound, tex, text, utils, web, x11
Section: misc
Description Описание пакета.
Описание состоит из двух частей: короткое описание (70 символов) на той же строке, и длинное описание на последующих строках, начинающихся с пробела.
В расширенном описании все переводы строки игнорируются. Для вставки \n используется одиночная точка.
Description: Short.
␣Long
␣goes here.
␣.
␣New line.
— связи и зависимости —
Depends Список пакетов через запятую, которые требуются для установки этого пакета.
После имени пакета можно в круглых скобках указать ограничение на версию, используя операторы: >, =. Если оператор не указан — используется >=
Depends: dpkg, libz (>= 1.2.3), jpeg (= 6b), png (
Pre-Depends Список пакетов, которые требуются в процессе установки этого пакета.
Эти зависимости могут потребоваться для скриптов установки пакета: например, пакет flash-installer требует wget
Можно использовать ограничения на версию (см. Depends).
Pre-Depends: wget (>= 1.0)
Conflicts Список пакетов, которые не могут быть установлены одновременно с этим.
Установка не удастся, если хоть один из перечисленных пакетов уже будет установлен.
Conflicts: crapscript
Replaces Список пакетов, файлы которых модифицируются этим пакетом.
Требуется в случае создания «пакета-патча», изменяющего что-либо: в противном случае при замене файлов чужого пакета возникнет ошибка при установке. У меня, например, такой пакет патчит UT2004 и убирает звук наводящейся ракетницы 🙂
Replaces: ut2004
Recommends Список пакетов, рекомендуемых к установке
Эти пакеты не обязательны, но обычно используются вместе с текущим
Recommends: superplatform
Suggests Список пакетов, предлагаемых к установке.
Эти пакеты не обязательны, но с ними прога работает ещё лучше 🙂 По идее, менеджер пакетов должен предлагать установить их.
Suggests: supersh-modules
Build-Depends (Только для Architecture: source)
Список пакетов, требуемых для компиляции исходников.
То же, что и Depends, но логически отделено.
Build-Depends: cmake
— экстра —
Installed-Size Размер файлов пакета в килобайтах.
Просто цифра, округлённая до ближайшего целого. Используется менеджером пакетов для определения суммарного требуемого объёма на диске.
Installed-Size: 3
Priority Приоритет пакета: насколько он важен в системе
Возможные значения: extra, optional, standard, important, required (такие пакеты не удаляются вообще!).
Priority: optional
Esssential Если установить этот атрибут в значение «yes», пакет нельзя будет удалить. Esssential: yes
Origin Строка: откуда получены программы в пакете. Обычно используется URL сайта автора, почта или имя. Origin: brain
X-Source Полная ссылка на *.tar.gz архив с исходниками X-Source: . *.tgz

Да, вот такие солидные возможности у контрольного файла 🙂
А в нашем примере он выглядит так:
Package: supersh
Version: 1.0-1
Section: misc
Architecture: all
Depends: bash, sed (>= 3.02-8)
Maintainer: o_O Tync
Description: Super Shell Script
␣A super example script.
␣.
␣It does nothing 🙂

DEBIAN/copyright: © / лицензия

Текст лицензии. Файл не обязателен, но лучше подчеркнуть своё авторство 😉

DEBIAN/changelog: история изменений

Changelog в специальном формате: используется dpkg для получения номера версии, ревизии, дистрибутива и важности пакета. Лучше посмотреть в официальной документации 😉 а я лишь приведу пример:
supersh (1.0-1) stable; urgency=medium

— o_O Tync Sun, 13 Dec 2009 00:11:46 +0300

DEBIAN/rules: правила компиляции

Используется для управления компиляцией пакета: это когда Architeture: source 🙂
См. официальную документацию

DEBIAN/conffiles: список файлов конфигурации

Обычно пакеты содержат болванки конфигурационных файлов, например, размещаемых в /etc. Очевидно, что если конфиг в пакете обновляется, пользователь потеряет свой отредактированный конфиг. Эта проблема легко решается использованием папок типа «config.d», содержимое которых включается в основной конфиг, заменяя собой повторяющиеся опции.
Файл «DEBIAN/conffiles» позволяет решить проблему иначе: он содержит список файлов конфигурации (по одному на строке). Если в текущей версии пакета один из этих файлов обновляется, то пользователь получает предупреждение о конфликте версий конфигов, и может выбрать: удалить, заменить, или сделать merge.
С этой ситуацией наверняка сталкивался каждый линуксоид, копавшийся в конфигах 🙂 А ноги растут отсюда.
На каждой строке должен быть полный абсолютный путь до каждого конфига. Например:
/etc/supersh/init.conf
/etc/supersh/actions.conf

DEBIAN/dirs: список папок для создания

«Список абсолютных путей к папкам, которые требуются программе, но по каким-либо причинам не создаются.» — гласит официальная документация. На практике – здесь перечисляются все папки, так или иначе используемые программой: и где лежат бинарники, и которые используются программой.
По одной на строке. Например:
/var/log/supersh
/var/lib/supersh
Удобно использовать для создания нескольких пустых папок.

DEBIAN/menu: создание пунктов меню

Хитрый файл для создания пунктов меню. У меня он так и не заработал 🙂 Складывается ощущение, что его содержимое используется либо в необычных оконных менеджерах, либо в каком-то консольном меню… или же использовалось ранее и было забыто 🙂
Пример:
?package(supersh):needs=»text» section=»Applications/Programming» title=»Super Shell Script» command=»/usr/bin/super.sh»
TODO: узнать зачем нужно. Об этом написано в man5 menufile , честно говоря я не вникал 🙂

UPD: Правильный способ добавления пункта меню

Файл /DEBIAN/menu создаёт неизвестно что и непонятно где: элементы графического меню всё равно не создаются. Поэтому будем делать правильно 🙂
В /usr/share/applications видим кучку *.desktop файлов: это и есть пункты меню. Они представляют собой текстовые файлы с синтаксисом наподобие ini-файла. Открываем, учимся, делаем так же и кладём получившийся *.desktop файл в usr/share/applications/ . Иконка для него должна лежать в usr/share/pixmaps .
После этого в postinst скрипт нужно добавить выполнение команды обновления меню update-menus :
if [ «$1» = «configure» ] && [ -x «`which update-menus 2>/dev/null`» ] ; then
update-menus
fi

Работа со скриптами установки пакета будет рассмотрена далее.
Спасибо Condorious за наводку 🙂

DEBIAN/md5sums: контрольные суммы файлов

Используется для проверки целостности пакета. Важный файл.
Заполняется так (cwd=корень пакета):
$ md5deep -r usr > DEBIAN/md5sums

DEBIAN/watch: мониторинг сайта, откуда была скачана прога

Функция полезна, если Вы мэйнтейните от нескольких десятков пакетов, и уследить за всеми обновлениями сложно.
Файл содержит инструкции для программ uscan и uupdate. Используя эту возможность, можно следить за сайтом, откуда были получены исходники пакета, и обеспечивать контроль качества дистрибутива в целом.
Пример:
# Site Directory Pattern Version Script
ftp.obsession.se /gentoo gentoo-(.*)\.tar\.gz debian uupdate

И ещё пример для uscan(1):
version=3
madwimax.googlecode.com/files/madwimax-(.*)\.tar\.gz

Лучше почитайте официальную документацию, такие мощные вещи нечастно требуются простым смертным 🙂

DEBIAN/cron.d: инсталляция заданий cron

Файл содержит кусок crontab для инсталляции. Пример объясняет всё:
#
# Launches super.sh periodically
#
0 4 * * * root [ -x /usr/bin/super.sh ] && usr/bin/super.sh

DEBIAN/inid.d: init-скрипт

В этот файл пишется содержимое init-скрипта. О написании init-скриптов в инете можно найти

Скриптинг

Мы подошли к самому интересному: встраиванию скриптов в deb пакеты. Скрипты позволяют управлять установкой, переустановкой и удалением пакета, выполняя действия, которые нельзя сделать простым копированием файлов в правильные места. Это может быть скачивание дополнительных файлов (как это делает flash-installer), изменение существующих, а также — вывод интерактивных (GUI или ncurses) диалогов, позволяющих пользователю сконфигурировать пакет под себя: например, mysql спрашивает какой установить пароль для root.
Все скрипты выполняются от пользователя root (а как же ещё :). Также они получают аргументы (которые обрабатывать не обязательно), конкретизирующие на каком именно этапе находится установка. Подробнее об этом здесь.

DEBIAN/(preinst|postinst|prerm|postrm): скрипты установки

Всего можно создать до четырёх скриптов в одном пакете:

Скрипт Назначение
DEBIAN/preinst Выполняется перед установкой пакета: он может подготовить что-либо для успешной установки
DEBIAN/postinst Выполняется сразу после установки пакета: он настраивает установленный пакет так, чтоб он был готов к работе. Здесь также выполняется интерактивная конфигурация пакета: это делается при помощи dh_input и файла DEBIAN/templates
DEBIAN/prerm Выполняется непосредственно перед удалением пакета: обычно этот скрипт подчищает установочные пути пакета так, чтоб ничего лишнего не завалялось 🙂
DEBIAN/postrm Выполняется сразу после удаления пакета: вычищает остатки

Обратите внимание, что ошибки, возникающие в этих скриптах никак не логируются: ничего интереснее кода возврата скрипта нигде не сохраняется, и логирование необходимо делать вручную! Пользователи одного моего пакета терпели неудачу при установке на Linux Mint, и не было даже возможности попросить у них лог ошибок (которого нету) чтобы выдебагать причину 🙂
Рекомендую использовать в начале каждого скрипта следующую болванку: она будет сохранять в syslog все возникающие ошибки.
#!/bin/bash
set -e # fail on any error
set -u # treat unset variables as errors

# ======[ Trap Errors ]======#
set -E # let shell functions inherit ERR trap

# Trap non-normal exit signals:
# 1/HUP, 2/INT, 3/QUIT, 15/TERM, ERR
trap err_handler 1 2 3 15 ERR
function err_handler <
local exit_status=$<1:-$?>
logger -s -p «syslog.err» -t «ootync.deb» «supersh.deb script ‘$0’ error code $exit_status (line $BASH_LINENO: ‘$BASH_COMMAND’)»
exit $exit_status
>

. Ваш код установочного скрипта .

exit 0

WARNING: болванка пока не тестировалась широко, проверьте лишний раз! На невозможность отладки наткнулся совсем недавно 🙂

DEBIAN/templates: шаблоны для диалогов

Как уже было сказано, в скрипте DEBIAN/config можно задавать пользователю вопросы: ввести строку, выбрать один из вариантов, поставить галочку,… Этим занимается «библиотека» bash функций debhelper пакета debconf, умеющая кроме этого ещё массу полезных вещей. Здесь их не рассматриваю 🙂
Файл DEBIAN/templates содержит данные, используемые при выводе диалоговых окон (GUI или ncurses). Файл содержит блоки, разделённые пустой строкой. Каждый блок определяет ресурсы, используемые в одном конкретном диалоговом окне.
Шапка для всех типов диалогов стандартная:
Template: supersh/template-name
Type: string
Default: Default-value
Description: Dialog-title
␣Dialog-text

Template — уникальный (в пределах одного пакета) идентификатор шаблона. Если в скрипте нужно вызвать определённый диалог — используется именно это имя.
Type — тип шаблона. Определены такие типы: string, password, boolean, select, multiselect, text, note, error.
Default-value — значение по умолчанию: пользователь может просто согласиться с ним.
Description — как и в контрольном файле, состоит из двух полей: короткое описание, и длинный текст. Первое — это заголовок «окна», второе — более развёрнутое описание того, что требуется от пользователя. Рекомендуется не использовать слов вроде «введите», а сразу суть: «Приветствие скрипта», «Точка монтирования»,…

Тип Описание шаблона
string Приглашение на ввод текстовой строки
password Приглашение на ввод пароля.
Для этого типа шаблона нет значения Default по понятным причинам 🙂
boolean Галочка 🙂 Имеет строковое значение «true» или «false»
select Возможность выбора одного из нескольких вариантов.
Варианты предлагаются в дополнительном атрибуте шаблона:
Choices: yes, no, maybe
multiselect Возможность выбора нескольких вариантов галочками.
Варианты предлагаются в дополнительном атрибуте шаблона:
Choices: sex, drugs, rock-n-roll
text Выводит на экран текст: некоторая не очень важная информация
note Выводит на экран текст: важная информация
error Выводит на экран текст: очень важная информация, критическая.

Для шаблонов text, note, error также нет значения Default, так как они лишь отображают информацию 🙂
Поиграемся с следующим шаблоном:
Template: supersh/greeting
Type: string
Description: Welcome message
␣The message you wish the script to welcome you with.
Default: Greetings, my master!

Основы использования debconf и debhelper

Это лишь работоспособные наброски. В оригинале почитать о шаблонах и работе с ними можно здесь: man 7 debconf-devel 🙂
Чтобы использовать шаблоны в своём скрипте настройки DEBIAN/config, необходимо сначала подключить функции debhelper:
. /usr/share/debconf/confmodule . Также этот файл нужно подключить в скрипте postinst: иначе скрипт DEBIAN/config вообще не выполнится!
Эти функции доступны в пакете debconf, не забудьте включить его в зависимости!
Примитивный пример использования. Файл DEBIAN/config
#!/bin/bash -e

# Подключение команд debconf
. /usr/share/debconf/confmodule

case «$1» in
configure|reconfigure)
# Запрос
db_input medium «supersh/greeting» || true # инициализация
db_go || true # вывод запроса на экран
# Обработка ответа
db_get «supersh/greeting» # Получение значения в переменную $RET
greeting=»$RET»
echo «$greeting» > /etc/supersh/greeting.txt
;;
*)
echo «config called with unknown argument \`$1′» >&2
exit 1
;;
esac
# Запрос
db_input medium «supersh/greeting» || true # инициализация
db_go || true # вывод запроса на экран

# Обработка ответа
db_get «supersh/greeting» # Получение значения в переменную $RET
greeting=»$RET»
echo «$greeting» > /etc/supersh/greeting.txt

Здесь уже кроется неприятная засада: обратите внимание, что функции db_input передаётся приоритет диалога medium. Для debconf можно установить минимальный приоритет: диалоги с приоритетом ниже которого не отображаются, а берётся значение по умолчанию (Default шаблона)! Чтобы этого ТОЧНО не случилось — используем приоритет critical 🙂 Кроме того, при установке из GUI порог вывода вопросов выше, и многие из них не отображаются вообще.
Возможные приоритеты: low — всегда используется default, medium — дефаулт обычно вполне подходит, high — дефаулт нежелателен, critical — внимание пользователя жизненно важно.
|| true используется чтобы скрипт не помер из-за ключика «-e» переданного bash.
В этом скрипте тоже рекомендуется использовать ту болванку для отлова ошибок, иначе с распространяемым пакетом могут возникнуть проблемы при отладке 🙂
Все тонкости использования debconf (функции, способы, параметры, коды ошибок) описаны в достаточно многословном мане: man debconf-devel .

И последнее: при удалении пакета командой purge — debconf должен также вычистить из своей базы сведения о пакете. Например, он сохраняет выбор пользователя при запросах db_input.
Чтобы вычистить эти данные, нужно в postinst-скрипт добавить следующее:
if [ «$1» == «purge» ] && [ -e /usr/share/debconf/confmodule ] ; then
. /usr/share/debconf/confmodule
db_purge
fi

Собираем пакет! 🙂

Ура! Все нужные файлы созданы, лежат по нужным папочкам. Теперь пора собирать пакет 🙂
Первое, что нужно сделать — это рекурсивно выставить всем файлам в корне пакета пользователя и группу root:root (или другие, если потребуется). Это нужно затем, что файлы пакета упаковываются в tar.gz архив который сохраняет и права доступа к файлам, и владельца. Потому нужно выполнить:
$ sudo chown -R root:root .
Однако делать это не обязательно. Есть отличная команда fakeroot которая при создании архива подменит владельца файлос root-ом.
В нашем примере, скрипт должен иметь бит выполнимости.
Потом выходим на папку назад, чтоб было видно корневую папку пакета, и пакет создаётся лёгким пинком сам:
$ fakeroot dpkg-deb —build supersh
Созданный пакет необходимо переименовать, чтобы он соответствовал порядку именования *.deb пакетов: _ _ .deb
$ mv supersh.deb supersh_1.0-1_all.deb
Всё, пакет готов!

Автоматическая проверка пакета

Существует утилита lintian, позволяющая проверить пакет и выявить типичные ошибки в его структуре. Делается это так:
$ lintian supersh_1.0-1_all.deb

Установка пакета

$ sudo dpkg -i supersh_1.0-1_all.deb

Создаём собственный репозиторий пакетов

Теперь у нас есть собственный пакет. Когда их будет несколько, и тем более — с зависимостями, окажется, что намного удобнее быстренько поднять собственный локальный микро-репозиторий, и включить его в список источников менеджера пакетов 🙂 Здесь я опишу быстрый HowTo «как создать свой репозиторий». Идею будет легко развить, почитывая соответствующую документацию 🙂
Сперва установим помощника:
$ sudo apt-get install reprepro

Описание будущего репозитория

Центр репозитория — его описание. Главное в нём — список компонент репозитория. Мы создадим компоненты «soft» и «games».
Выберите папку для будущего репозитория. Все действия производятся из её корня.
Создаём файл conf/distributions следующего содержания:
Description: my local repository
Origin: Ubuntu
Suite: testing
AlsoAcceptFor: unstable experimental
Codename: karmic
Version: 5.0
Architectures: i386 amd64 source
Components: soft games
UDebComponents: soft games

В нашем деле создания простого репозитория все поля не играют принципиальной роли, и используются лишь для визуального определения «что есть что» 🙂

Создание репозитория

Репозиторий описан! Теперь сгенерируем болванку на основе описания. Команды выполняются в корне репозитория:
$ reprepro export
$ reprepro createsymlinks
И добавим готовый репозиторий в /etc/apt/sources.list:
deb file:///path/to/repo/ karmic soft games
Этот репозиторий можно также расшарить при помощи веб-сервера.

Управление пакетами в репозитории

В корень репозитория кладём *.deb файлы для добавления, и добавляем их в компоненту soft дистрибутива karmic:
reprepro -C soft includedeb karmic *.deb
теперь пакеты доступны из менеджера пакетов 🙂
Удаление пакетов:
reprepro -C soft remove karmic supersh

Финиш

В статье рассмотрены материалы по созданию deb пакетов. Акцент сделан на моментах, для которых в сети нет достаточно наглядного описания. Надеюсь, что моя попытка изложить просто и понятно не провалилась 🙂
Домашнее задание :)) — вполне неплохо документированные вещи, которые легко найти в man’ах и статьях:

  • Создание source пакетов, компилирующих исходники: на примере Zabbix об этом отлично рассказал хабраюзер mahoro в своей статье
  • Debconf, debhelper в конфигурационных скриптах: читаем маны по debconf-devel и debhelper. Они также позволяют создать скелет пакета командой dh_make.
  • Продвинутые способы создания документации в пакетах: файлы DEBIAN/docs, DEBIAN/manpage.*
  • Создание init скриптов
  • Управление заданиями cron
  • Подписывание репозитория ключём gpg

UPD: @ICD2 подсказывает, что есть GUIшная прога для создания пакетов: GiftWrap.

источник

Добавить комментарий

Adblock
detector