Проект Debian распространяется как набор пакетов, их 90 000, по состоянию на выпуск Debian 10 «buster». Эти пакеты делятся на три области: main, contrib и non-free, главным образом, на основе лицензионных требований, например, Debian Free Software Guidelines (DFSG).
Основная область содержит свободное программное обеспечение, соответствующее DFSG. Область contrib содержит свободное программное обеспечение, соответствующее DFSG, но полагающееся на несвободное программное обеспечение для компиляции или выполнения. Наконец, область non-free содержит несвободные пакеты, которые не соответствуют DFSG, но могут быть использованы для дистрибуции. Основной репозиторий считается частью Debian, но ни contrib, ни non-free репозиторий таковыми не являются. Два последних поддерживаются и предоставляются только для удобства пользователей.
Если вы хотите установить любой несвободный пакет, поддерживаемый Debian, вам нужно включить репозитории contrib и non-free. Для этого откройте /etc/apt/sources.list в текстовом редакторе и добавьте «contrib non-free» к каждому источнику.
Debian 11(Mate) после установки — установка программ, flatpak, virt mamager…
Ниже приведён пример /etc/apt/sources.list для Debian 10 «buster» Release.
deb http://deb.debian.org/debian/ buster main contrib non-free deb-src http://deb.debian.org/debian/ buster main contrib non-free deb http://security.debian.org/debian-security buster/updates main contrib non-free deb-src http://security.debian.org/debian-security buster/updates main contrib non-free # buster-updates, previously known as ‘volatile’ deb http://deb.debian.org/debian buster-updates main contrib non-free deb-src http://deb.debian.org/debian buster-updates main contrib non-free
После изменения источников пакетов выполните следующую команду для загрузки индексных файлов пакетов для репозиториев contrib и non-free.
# apt update
Теперь вы готовы к поиску и установке любого несвободного пакета в Debian.
Источник: sysadmin78.ru
Debian. Шпаргалка сисадмина. Управление пакетами
В статье я постараюсь описать теорию относительно внутреннего устройства пакетов, нюансов их использования и ограничений, а также основные программы для управления пакетами в порядке уменьшения их сложности. Начнем с обзора строения пакетов .
Теоретическая часть
Большинство информации в теоретической части взято из справочных страниц, официальной документации на русском и английском языках.
Общая информация
Все пакеты для Debian можно разделить на два типа 1 :
Двоичные пакеты (binary) — содержат исполняемые файлы, файлы настроек, справочные страницы, информацию об авторских правах. Пакеты поставляются в файлах с расширением .deb (специфичен именно для Debian-систем).
Debian.ч5. Пакетная установка программ.
Пакеты исходного кода (source) — содержат описание пакета, файл с tar-архивом немодифицированного исходного кода (расширение .orig.tar.gz) и обычно файла, содержащего особые Debian-специфичные изменения к оригинальному исходному коду (расширение .diff.gz)
Имена файлов пакетов включают в себя последовательно общее имя пакета, номер ревизии, архитектуру.
Помимо обычных пакетов существуют также виртуальные 2 . Они обладают идентичной функциональностью, но имеют разные названия. Оба пакета предоставляют одно и то же дополнительное имя пакета, которое и является виртуальным. При этом для разрешения зависимостей может использоваться как первый, так и второй реальные пакеты, если вдруг какой-либо из них понадобится для другой программы.
Файл control
Вся сопроводительная информация о пакете находится в файле control. Некоторые атрибуты 3 в этом файле рассмотрены ниже, назначение остальных легко можно понять исходя из их названия. Рассмотрим для примера вывод файла control для пакета mysql-server-5.5:
Приоритет (priority) 4 — может принимать значения требуемый (required), важный (important), стандартный (standard), дополнительный (optional) и экстра (extra). Все типы указаны в порядке уменьшения их важности для операционной системы. Если без требуемых пакетов операционная система не сможет функционировать нормально, то экстра и дополнительные пакеты в принципе не нужны для работы системы, они добавляют дополнительный функционал.
В нижней части текста можно встретить атрибуты, которые содержат списки определенных пакетов. Некоторые из этих пакетов могут быть установлены по желанию, а какие-то должны присутствовать обязательно. В этом случае говорят, что пакет 5 : зависит (depends), пред-зависит (pre-depends), рекомендует (reccomends), предлагает (suggests), ломает (breaks), конфликтует (conflict), предоставляет (provides), заменяет (replace), наращивает (enhances). Конечно же все эти поля содержат имена других пакетов, без которых работа основного невозможна (как в случае с пакетами в атрибуте depends), которые добавляют дополнительный функционал (reccomends, suggests), или которые могут даже заменять уже существующие в системе пакеты (replace) и так далее.
Почти в самом низу находятся данные файла conffile 6 . Он необходим для определения конфигурационных файлов, которые нельзя заменять при обновлении пакета, чтобы сохранить настройки.
Сценарии установки
Помимо данных самого приложения и информации о нем, в пакетах также поставляются сценарии, которые определяют необходимые действия до/после установки/удаления пакета. Все сценарии установленного пакета хранятся в каталоге низкоуровневой утилиты управления пакетами — dpkg — /var/lib/dpkg/info с соответствующим расширением (проверим это на примере все того же mysql-server-5.5):
Вот за что отвечает каждый сценарий 7 :
.preinst — выполняется перед распаковкой пакетов, обычно останавливает связанные с ними службы;
.postinst — выполняется соответственно после распаковки пакета и в большинстве случае служит для настройки только что распакованного пакета — либо самостоятельной, либо с помощью пользователя путем запроса каких-либо данных и/или вывода предупреждений. Конечно же остановленные на этапе выполнения сценария .preinst службы должны быть запущены;
.prerm — как можно догадаться из названия, этот сценарий запускается перед удалением пакета и обычно останавливает все зависящие от него службы;
.postrm — выполняется в самую последнюю очередь после удаления пакета, запускает обратно необходимые службы, подчищает все оставшиеся от пакета данные.
Вообще процессы установки/удаления/обновления пакетов содержат достаточно много действий, это не просто распаковка различных файлов в соответствующие им каталоги системы. Все эти нюансы также подробно расписаны в официальных руководствах 8 .
Утилиты управления пакетами
Существует достаточно много утилит управления пакетами, например: apt, aptitude, dpkg, dselect, synaptic и другие. Все они обладают практически идентичным функционалом для «повседневного» использования, но различаются некоторыми другими функциями, интерфейсом и т.д.
В данном случае меня интересуют утилиты командной строки для администрирования прежде всего серверов, не обладающих графическим интерфейсом, а потому я собираюсь рассмотреть три наиболее часто используемые утилиты — dpkg, apt, aptitude.
Надо понимать, что высокоуровневые утилиты, такие как aptitude, основаны на apt, которая в свою очередь использует низкоуровневую dpkg 9 .
Основные различия
Основные различия заключаются в следующем 10 :
- является основным низкоуровневым инструментом для работы с пакетами, умеет работать с файлами .deb, в отличие от apt и aptitude, работает только с существующими пакетами, загружать ничего не умеет, пользуйтесь этим инструментом очень аккуратно;
- не умеет работать с зависимостями и если устанавливаемому пакету нужны какие-либо другие, dpkg выкинет ошибку и вам придется подгружать зависимости вручную;
- ведет очень подробные логи в файле /var/log/dpkg.log;
- рекомендуют использовать для обновлении системы при переходе между версиями дистрибутивов, а также просто при установке или обновлении пакетов благодаря более надежному механизму разрешения зависимостей пакетов;
- apt-get и apt-cache работают только в режиме командной строке;
- apt-cache предоставляет возможность поиска с использованием регулярных выражений только в именах и описаниях пакетов;
- умеет работать с предпочтениями 11 только через файл /etc/apt/preferences, в отличие от aptitude;
- менее требовательна к аппаратным ресурсам.
- крайне не рекомендуют использовать для обновления системы при переходе от одной версии дистрибутива к другой; встречаются ситуации с массовым удалением пакетов при обновлении в нестабильных сборках;
- является наиболее универсальным функциональным инструментом на основе apt;
- умеет работать как в режиме командной строки, так и в интерактивном режиме;
- наиболее полезная при выполнении повседневных задач управления пакетами — усиленные возможности поиска (поддерживаются регулярные выражения при поиске в метаданных пакета), подробный анализ существующих пакетов, управление устаревшими пакетами, удобный доступ ко всем версиям пакета;
- уступает по производительности другим утилитам.
Базовые функции
Поскольку все описанные выше утилиты выполняют собственно одну и ту же задачу, вполне логично, что у них есть ряд одинаковых основных функций 12 . Многие из них будут рассмотрены ниже. Поскольку dpkg работает несколько по-иному, её обзор будет отдельно.
| aptitude | apt-get/apt-cache | описание |
| aptitude update | apt-get update | обновление метаданных локального архива пакетов |
| aptitude install foo | apt-get install foo | установить актуальную на данный момент версию пакета foo со всеми необходимыми зависимостями |
| aptitude safe-upgrade | apt-get upgrade | установить актуальные на данный момент версии имеющихся в системе пакетов без удаления существующих |
| aptitude full-upgrade | apt-get dist-upgrade | установить актуальные на данный момент версии имеющихся в системе пакетов с удалением существующих, если это необходимо |
| aptitude remove foo | apt-get remove foo | удаление пакета foo без удаления его конфигурационных файлов |
| — | apt-get autoremove | удаление зависимостей от отсутствующих в системе пакетов |
| aptitude purge foo | apt-get purge foo | удаление пакета foo вместе с его конфигурационными файлами |
| aptitude clean | apt-get clean | очистка локального хранилища полученных файлов пакетов |
| aptitude autoclean | apt-get autoclean | как и предыдущая команда, но удаляет также пакеты, которые больше не могут быть получены |
| aptitude show foo | apt-cache show foo | отобразить детальную информацию о пакете foo |
| aptitude search | apt-cache search | поиск в имени и описании пакета в соответствии с заданным регулярным выражением |
| aptitude why | — | объяснение почему определенный пакет должен быть установлен в системе |
| aptitude why-not | — | объяснение почему определенный пакет не должен быть установлен в системе |
Расширенные функции
Наиболее часто встречающиеся расширенные функции подробно описаны в официальных руководствах, я позволю себе позаимствовать также и эту информацию, осуществив её перевод и снабдив необходимыми на мой взгляд комментариями.
| Команда | Описание |
| COLUMNS=120 dpkg -l | |
| dpkg -L | полный список установленных файлов для определенного пакета |
| dpkg -L | egrep ‘/usr/share/man/man.*/.+’ | список справочных страниц определенного пакета |
| dpkg -S | список файлов установленных пакетов, которые имеют совпадения с шаблоном |
| apt-file search | список пакетов из локального архива, в именах которых имеется совпадение с шаблоном |
| apt-file list | список содержимого пакетов из архива, в названии которых имеется совпадение с шаблоном |
| dpkg-reconfigure 13 | перенастроить определенный пакет |
| dpkg-reconfigure -p=low | перенастроить определенный пакет с заданием минимального приоритета показываемых вопросов |
| configure-debian 14 | централизованная перенастройка пакетов, использующих debconf |
| dpkg —audit | анализ системы на предмет частично установленных пакетов |
| dpkg —configure -a | перенастроить распакованный пакет. Вместе с опцией -а все распакованные, но не настроенные пакеты будут настроены |
| apt-cache policy | проверяет статус пакетов |
| apt-cache madison | показывает доступную версию и информацию об архивах пакета |
| apt-cache showsrc | показывает исходную информацию о пакете |
| apt-get build-dep | установка пакетов, необходимых для компиляции пакетов исходных кодов 15 |
| aptitude build-dep | install required packages to build package |
| apt-get source | скачивание пакета исходного кода 16 |
| dget | загрузка пакета исходных кодов (может использоваться в сценарии установки ПО из нестабильной ветки дистрибутива 17 ) |
| dpkg-source -x _-.dsc | dpkg-source входит в пакет dpkg-dev 18 . команда означает сборку 19 пакета из трех файлов («*.orig.tar.gz», «*.debian.tar.gz»/»*.diff.gz») |
| debuild binary 20 | сборка пакета |
| make-kpkg kernel_image | сборка ядра |
| make-kpkg —initrd kernel_image | сборка ядра с ключом initrd |
| dpkg -i _-_.deb | установка пакета |
| debi _-_.dsc | установка .dsc-пакета в систему |
| dpkg —get-selections ‘*’ >selection.txt | сохранить список пакетов и их статусов в файл |
| dpkg —set-selections | задать список состояний выбора пакетов |
| echo hold | dpkg —set-selections | установить состояние определенного пакета в hold |
На этом я закончу обзор управления пакетами, несмотря на то, что огромная часть информации так и не была затронута. Тематика менеджеров пакетов на удивление исчерпывающе описана в достаточно большом количестве официальных источников. Ниже представлены лишь некоторые из них, которые я использовал при написании статьи:
Также могут быть полезны ресурсы смежных дистрибутивов:
В любом случае я не ставил задачу описать все нюансы работы с пакетами. Статья предназначена прежде всего для аккумулирования опыта из общедоступных источников, коллекционирования ссылок на наиболее полезные ресурсы и небольшого обзора самых фундаментальных положений и функций.
- Часто задаваемые вопросы о Debian GNU/Linux — 7.1 Что такое пакет Debian?↩
- Часто задаваемые вопросы о Debian GNU/Linux — 7.8 Что такое виртуальный пакет?↩
- Debian Policy Manual — 5.6 List of fields↩
- Debian Policy Manual — 2.5 Priorities↩
- Debian Policy Manual — Chapter 7 Declaring relationships between packages↩
- Часто задаваемые вопросы о Debian GNU/Linux — 7.5 Зачем нужен файл conffile?↩
- Часто задаваемые вопросы о Debian GNU/Linux — 7.6 Зачем нужны сценарии preinst, postinst, prerm и postrm?↩
- Debian Reference — 2.1.7. The event flow of the package management↩
- Часто задаваемые вопросы о Debian GNU/Linux — 8.1 Какие программы для управления пакетами имеются в Debian?↩
- Debian Reference — 2.2.1. apt-get / apt-cache vs. aptitude↩
- AptPreferences↩
- Debian Reference — 2.2.2. Basic package management operations with the commandline↩
- dpkg-reconfigure↩
- Package: configure-debian↩
- APT HOWTO (Obsolete Documentation) — 6.2 Пакеты, необходимые для компиляции пакетов исходных текстов↩
- APT HOWTO (Obsolete Documentation) — 6.1 Скачивание пакетов исходных текстов↩
- SimpleBackportCreation↩
- Package: dpkg-dev↩
- Руководство начинающего разработчика Debian — Глава 6. Сборка пакета↩
- debuild↩
- ← Apache Cassandra. Начальная настройка
- Debian. Шпаргалка сисадмина. Информация об устройствах →
Источник: blog.bissquit.com
#!/bin/sh
Пакетная система Debian: низкоуровневая работа с deb-пакетами
Формат deb-пакета
Краеугольный камень пакетной системы Debian — это deb-пакет (см. deb(5)), представляющий из себя архив формата ar, внутри которого содержится три файла:
1. debian-binary — текстовый файл, содержащий версию формата deb-пакета, в данный момент это 2.0. Программы, работающие с deb-пакетами, должны читать только первую строку этого файла и не падать, если минорная версия вдруг поменяется (например, станет 2.1).
2. control.tar.gz — служебная информация о пакете, скрипты, вспомогательные файлы (см deb-control(5)). Должен содержать только файлы, единственная папка, которая может присутствовать — «.» (текущая директория). В этот архив обязательно должен входить файл control, его минимальное содержимое рассмотрим чуть ниже.
3. data.tar — собственно файлы, устанавливаемые в систему. Чаще всего этот файл сжат каким-нибудь архиватором (поддерживаются расширения .gz, .xz, .bz2, .lzma), чаще всего в архивах встречается data.tar.gz.
Указанный порядок следования файлов в архиве обязателен. Если в этом архиве требуется разместить еще какие-нибудь файлы (не представляю, зачем это может кому-нибудь понадобиться), они должны находиться перед data.tar.gz, т.е. последний файл в архиве всегда data.tar. Но если сообщество когда-нибудь решит добавить в формат deb еще файлы, они будут помещены после data.tar.
Файл control в архиве control.tar.gz описывает назначение, версию и зависимости пакета, его формат более-менее подробно описан в deb-control(5). Пересказывать всю справку сейчас не буду, опишу лишь минимальное содержимое, необходимое для взаимодействия с инфраструктурой dpkg:
Package: имя пакета Version: строка версии (при выборе политики назначения версий следует придерживаться deb-version(5)) Maintainer: John Doe (человек, поддерживающий пакет, а не автор программы) Description: короткое описание пакета Длинное описание, на несколько строк. Каждая строка, входящая в длинное описание, должна начинаться с пробела
Работа с пакетами средствами ar
Теоретически данной информации должно быть достаточно, чтобы собрать простейший пакет «на коленке» и установить его в систему. Пусть наш пакет (назовем его test) просто добавляет в систему файл /usr/share/example-content/test со строчкой «test». Сделаем архив data.tar.gz со структурой папок и единственным файлом, а также файлик debian-binary:
$ mkdir -p usr/share/example-content/ $ echo test > usr/share/example-content/test $ tar czf data.tar.gz usr $ echo 2.0 > debian-binary
$ cat control Package: test Version: 1.0 Maintainer: Dummy Maint Description: test package Test package created on my own knees. $ tar czf control.tar.gz control
Теперь соберем все воедино:
$ ar -qS test-1.0.deb debian-binary control.tar.gz data.tar.gz
В текущем каталоге должен появиться файл test-1.0.deb . Его «физическое» содержимое можно просмотреть с помощью следующей команды:
$ ar t test-1.0.deb debian-binary control.tar.gz data.tar.gz
Посмотреть файл debian-binary:
$ ar p test-1.0.deb debian-binary 2.0
Посмотреть список файлов в пакете:
$ ar p test-1.0.deb data.tar.gz|tar -tzf — usr/ usr/share/ usr/share/example-content/ usr/share/example-content/test
Посмотреть содержимое файла control:
$ ar p test-1.0.deb control.tar.gz |tar -O -xzf — control Package: test Version: 1.0 Maintainer: Dummy Maint Description: test package Test package created on my own knees.
Можно установить этот пакет и убедиться, что файл /usr/share/example-content/test успешно создан, но лучше этого не делать, поскольку из-за недостатка информации в control в пакетной системе может появиться мусор:
$ sudo dpkg -i test-1.0.deb Selecting previously deselected package test. (Reading database . 97631 files and directories currently installed.) Unpacking test (from test-1.0.deb) . Setting up test (1.0) .
Работа с пакетами средствами dpkg-deb
Все вышеописанное позволяет управляться с deb-пакетами на самом низком уровне, не имея под рукой ничего, кроме стандартных средств Unix (доподлинно известно, что программа ar входила в состав первых Unix 1970х годов). Однако, как несложно догадаться, есть и более высокоуровневые способы создания пакетов и изучения их содержимого. В частности, если уж так необходимо поковыряться с пакетом на низком уровне, все вышеописанные действия настоятельно рекомендуется выполнять с помощью утилиты dpkg-deb(1).
Создание пакета средствами dpkg-deb
Минимальный формат вызова команды dpkg-deb для построения пакета следующий:
dpkg-deb -b исходная_папка
Все, что находится в исходной папке, кроме директории DEBIAN, помещается в data.tar.gz. Содержимое DEBIAN будет использовано для создания control.tar.gz, в частности, будет прочитан и проанализирован файл control и в случае каких-либо ошибок (отсутствует одно из необходимых полей или эти поля имеют неправильные значения) пакет просто не будет создан. Процесс создания нашего тестового пакета с нуля теперь выглядит так (в последней команде предполагается, что в текущей папке остался файл control от сборки пакета средствами ar):
$ mkdir -p test-1.1/usr/share/example-content/ test-1.1/DEBIAN $ echo test 1.1 > test-1.1/usr/share/example-content/test $ sed ‘s/Version: 1.0/Version: 1.1/g’ control > test-1.1/DEBIAN/control
Попытаемся собрать пакет:
$ dpkg-deb -b test-1.1 warning, in file ‘test-1.1/DEBIAN/control’ near line 5 package ‘test’: missing architecture dpkg-deb: building package `test’ in `test-1.1.deb’. dpkg-deb: warning: ignoring 1 warnings about the control file(s)
Несмотря на отсутствие важного, но не необходимого поля Architecture, был создан пакет test-1.1.deb. Добавим поле и пересоздадим пакет:
$ sed -i «1a Architecture: all» test-1.1/DEBIAN/control $ dpkg-deb -b test-1.1 dpkg-deb: building package `test’ in `test-1.1.deb’
Еще одна немаловажная деталь. Как правило, в названии файла пакета указывается его архитектура, а команда dpkg-deb -b назвала файл по имени папки, из которой он был создан. Если бы папка называлась ololo, то мы получили бы ololo.deb. Чтобы файл пакета автоматически именовался в формате имя-версия-архитектура, при вызове dpkg -b необходимо указывать папку, куда будет положен итоговый архив, например, текущую. Тогда все компоненты имени файла будут извлечены из control:
$ cp -R test-1.1 ololo $ dpkg -b ololo dpkg-deb: building package `test’ in `ololo.deb’. $ dpkg -b ololo . dpkg-deb: building package `test’ in `./test_1.1_all.deb’.
Теперь всё относительно нормально, продолжаем изучение возможностей dpkg-deb на примере нового пакета.
Получение информации о пакете
Узнать версию формата deb, размер пакета и содержимое файла control:
$ dpkg -I test_1.1_all.deb new debian package, version 2.0. size 644 bytes: control archive= 259 bytes. 160 bytes, 6 lines control Package: test Architecture: all Version: 1.1 Maintainer: Dummy Maint Description: test package Test package created on my own knees.
Список файлов, устанавливаемых в систему (кроме служебных):
$ dpkg -c test_1.1_all.deb drwxr-xr-x bvk/bvk 0 2010-10-22 13:21 ./ drwxr-xr-x bvk/bvk 0 2010-10-22 13:21 ./usr/ drwxr-xr-x bvk/bvk 0 2010-10-22 13:21 ./usr/share/ drwxr-xr-x bvk/bvk 0 2010-10-22 13:21 ./usr/share/example-content/ -rw-r—r— bvk/bvk 9 2010-10-22 13:21 ./usr/share/example-content/test
Обратите внимание на владельца устанавливаемых файлов и каталогов: это не root, а некий пользователь. Чтобы исправить эту проблему, можно собирать пакеты из-под root’а, либо воспользоваться специальной утилитой fakeroot из одноименного пакета. Она перехватывает системные вызовы chmod(2) и stat(2) для файлов, и возвращает значения, как если бы файл принадлежал пользователю root. Небольшой пример:
$ id uid=1000(bvk) gid=1000(bvk) . $ touch trololo $ ls -l trololo -rw-r—r— 1 bvk bvk 0 2010-10-22 13:23 trololo $ fakeroot ls -l trololo -rw-r—r— 1 root root 0 2010-10-22 13:23 trololo
Думаю, принцип понятен. Пересоберем пакет еще более правильно:
$ fakeroot dpkg -b test-1.1 . dpkg-deb: building package `test’ in `test_1.1_all.deb’. $ dpkg -c test_1.1_all.deb drwxr-xr-x root/root 0 2010-10-22 13:25 ./ drwxr-xr-x root/root 0 2010-10-22 13:25 ./usr/ drwxr-xr-x root/root 0 2010-10-22 13:25 ./usr/share/ drwxr-xr-x root/root 0 2010-10-22 13:25 ./usr/share/example-content/ -rw-r—r— root/root 9 2010-10-22 13:25 ./usr/share/example-content/test
Теперь наконец ок.
Можно получаить информацию о пакете в заданном формате:
$ dpkg-deb -W —showformat=’$-$-$ ($)n’ test_1.1_all.deb test-1.1-all (Dummy Maint )
Список полей, которые можно указать в –showformat, можно узнать из вывода команды dpkg-deb -I
Подать на STDOUT архив data.tar.gz из пакета (уже «разжатый»), может быть полезно для извлечения только некоторых файлов:
$ dpkg-deb —fsys-tarfile test-1.0.deb |tar -Ox usr/share/example-content/test test
Перепаковка пакета
Пожалуй, теперь наступил момент применить свежеполученные знания на практике 🙂 Часто возникает следующая проблема: из некоего источника поступил пакет с некорректными зависимостями, например, требуется устаревший пакет, отсутствующий в системе и всех репозиториях, но доподлинно известно, что другой, уже установленный пакет предоставляет нужную функциональность. В скачанном пакете требуется изменить файл control, убрав или исправив зависимость. Правильно было бы скачать и распаковать исходник пакета (apt-get source), произвести необходимые изменения в скриптах сборки, установить все необходимые для пересборки библиотеки и окружение и т.д. и т.п., но для частного использования (т.е. без распространения по репозиториям) достаточно просто распаковать пакет, изменить необходимые файлы и запаковать обратно. Проиллюстрирую последовательность действий на примере невинного пакета hello:
$ aptitude download hello Get:1 http://yum.fireground.ru/ubuntu/mirror/ maverick/main hello i386 2.5-1 [34.4kB] Fetched 34.4kB in 0s (824kB/s) # да-да, я сижу под убунтой и описываю debian # распаковать содержимое пакета в папку hello (если не существует, будет создана): $ dpkg-deb -x hello_2.5-1_i386.deb hello # распаковать содержимое control.tar.gz в hello/DEBIAN $ dpkg-deb -e hello_2.5-1_i386.deb hello/DEBIAN # что-нибудь поменять в control, например, версию пакета: $ sed -i ‘s/Version: .*$/Version: 2.5-1test/’ hello/DEBIAN/control # собрать новый пакет: $ fakeroot dpkg -b hello/ . dpkg-deb: warning: ‘hello//DEBIAN/control’ contains user-defined field ‘Original-Maintainer’ dpkg-deb: building package `hello’ in `./hello_2.5-1test_i386.deb’. dpkg-deb: warning: ignoring 1 warnings about the control file(s)
Пакет собран. Убедиться, в том, что в нем нет ошибок из-за немного нетрадиционного способа сборки, можно с помощью программы lintian:
$ sudo aptitude install lintian . $ lintian hello_2.5-1test_i386.deb $ echo $? 0
Об установке пакетов в систему, механизме зависимостей, структуре репозиториев и еще более правильных способах сборки пакетов читайте в следующих статьях 🙂
Источник: www.binsh.ru