Пакетные менеджеры apt и apt-get

The Debian GNU/Linux FAQ
Глава 6 — Основы системы управления пакетами Debian

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

Двоичные (Binary) пакеты, которые содержат выполняемые и конфигурационные файлы, страницы man/info, информацию об авторских правах и другую документацию. Эти пакеты распространяются в архивах специального формата Debian (см. Какой формат у двоичных пакетов Debian?, раздел 6.2); их обычно можно отличить по расширению ‘.deb’. Двоичные пакеты могут быть распакованы при помощи утилиты dpkg ; подробности даны в странице руководства.

Исходные (Source) пакеты, которые состоят из .dsc файла описывающего исходный пакет (включая имена файлов описанных ниже), .orig.tar.gz файла, содержащего оригинальный исходный текст программы в архивном формате tar.gz и, обычно, .diff.gz файл содержащий специфические для Debian изменения к оригинальным исходным текстам. Утилита dpkg-source запаковывает и распаковывает исходные архивы Debian; детали описаны на страницах руководства.

При установке программного обеспечения система управления пакетами использует «зависимости» (dependencies), которые тщательно определены сопровождающим пакет. Эти зависимости указаны в файле control , связанном с каждым пакетом. Например пакет содержащий GNU компилятор C ( gcc ) «зависит» от пакета binutils , в котором содержатся компоновщик и ассемблер. Если пользователь попытается установить gcc до того как установит binutils , то система управления пакетами (dpkg) выдаст сообщение об ошибке, содержащее указание на необходимость установить binutils , и прервет установку пакета. (Обычно, эта возможность может быть отключена настойчивым пользователем, см. dpkg(8) .) Более подробно смотри ниже в Что подразумевают говоря, что пакет Зависит/Рекомендует/Предполагает/Конфликтует/Заменяет/Предоставляет (Depends/Recommends/Suggests/Conflicts/Replaces/Provides) другой пакет?, раздел 6.9.

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

манипуляций и управления пакетами и частями пакетов,

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

помощи разработчику в сборке пакетов,

помощи пользователю в установке пакетов, размещенных на удаленном FTP сервере.

6.2 Какой формат у двоичных пакетов Debian?

«Пакет» Debian, или архив Debian, содержит выполнимые файлы, библиотеки и документацию связанные с определенным набором программ или с множеством взаимосвязанных программ. Как правило, файл архива Debian имеет расширение .deb .

Внутренний формат двоичных пакетов Debian описан в странице руководства deb(5) . Этот внутренний формат может быть изменен (в различных выпусках Debian GNU/Linux), поэтому всегда используйте dpkg-deb(1) для различных манипуляций с файлами .deb .

6.3 Почему у пакетов Debian такие длинные имена?

Имена двоичных пакетов Debian удовлетворяют следующему соглашению: _-.deb

Заметим, что foo полагается именем пакета. Для проверки имени пакета связанного с конкретным .deb файлом можно воспользоваться следующими методами:

просмотреть файл «Packages» в каталоге FTP сервера, где хранился архив Debian. Этот файл содержит блоки описаний для каждого пакета; первое поле в каждом блоке — имя пакета.

использовать команду dpkg —info foo_VVV-RRR.deb (где VVV и RRR — версия и ревизия проверяемого пакета). При этом, среди прочей информации, выводится имя пакета соответствующее архивному файлу.

Компонент VVV — номер версии определяемый разрабочиком программы. На формат версии нет каких либо ограничений, он может быть различным, напр., «19990513» или «1.3.8pre1».

Компонент RRR номер ревизии Debian, определяется разработчиком Debian (или конкретным пользователем, если тот хочет построить пакет сам). Этот номер соответствует количеству пересмотров, которому подвергся пакет, так, при каждом пересмотре, обычно, вносятся изменения в Debian Makefile ( debian/rules ), управляющий файл Debian ( debian/control ), сценарии инсталяции и удаления ( debian/p* ), или в файлы конфигурации используемые с пакетом.

6.4 Что это за управляющий (control) файл Debian?

Спецификации содержимого управляющего файла Debian приводятся в «Руководстве по пакетам Debian» (Debian Packaging manual), глава 4, см. Какая ещё документация существует для системы Debian?, раздел 11.1.

Короткий пример файла control для пакета Debian hello приведен ниже:

Поле Package определяет имя пакета. Это имя по которому инструменты упраления пакетами будут его опознавать. Обычно такое же, но не обязательно, как первая часть имени файла архива Debian.

Поле Version определяет версию разработчика и (в последнем компоненте) номер ревизии пакета данной программы как раскрыто в Почему у пакетов Debian такие длинные имена?, раздел 6.3.

Поле Architecture определяет тип процессора для которого был скомпилирован данный пакет.

Поле Depends содержит список пакетов, которые должны быть установлены для успешной установки данного пакета.

Installed-Size показывает сколько дискового пространства займет установленный пакет. Этот параметр может использоваться программами установки для определения остающегося дискового пространства.

Строка Section определяет «раздел», в котором хранится пакет Debian на FTP сервере. Это имя подкаталога (в одном из основных каталогов, см. Что содержат каталоги в FTP-архивах Debian?, раздел 5.1) в котором хранится пакет.

Поле Priority показывает насколько важным является пакет для установки; некоторые программы, напр., dselect или console-apt могут сортировать пакеты по категориям. См. Что такое Требуемый/Важный/Стандартный/Необязательный/Дополнительный (Required/Important/Standard/Optional/Extra) пакет?, раздел 6.7.

В поле Maintainer указан e-mail адрес человека, ответственного за поддержку данного пакета.

В поле Description дается краткое описание возможностей, предоставляемых пакетом.

Для более подробной информации о полях, которые может иметь пакет, смотрите главу 4 Руководства по пакетам Debian, «Управляющие файлы и их поля.»

6.5 Что такое Debian conffile?

Conffile содержит список файлов конфигурации (обычно помещаемых в /etc ), которые система управления пакетами не будет перезаписывать при обновлении пакета. Это гарантирует, что содержимое файлов конфигурации будет сохранено и позволяет обновлять пакеты не прерывая работу системы.

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

и смотрите в строке «Conffiles:».

6.6 Что это за сценарии preinst, postinst, prerm и postrm?

Это выполняемые сценарии, которые автоматически запускаются перед или после установки пакета. Вместе с файлом control , эти файлы являются частью «управляющего» раздела архивного файла Debian.

Данный сценарий выполняется перед тем, как пакет будет распакован из .deb файла. Многие сценарии ‘preinst’ останавливают сервисы, которые будут обновлены пакетом, до завершения установки или обновления.

Этот сценарий, обычно, завершает требуемую настройку пакета после того, как он был извлечен из .deb файла. Часто, сценарий ‘postinst’ запрашивает у пользователя различные параметры и/или предупреждает пользователя, что если он примет значения по-умолчанию, то позже прийдется переконфигурировать пакет. Многие сценарии также ‘postinst’ выполняют команды, необходимые для запуска или перезапуска сервиса после установки или обновления пакета.

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

Этот сценарий, обычно изменяет ссылки или другие файлы, связанные с пакетом, и/или удаляет файлы созданные пакетом. (См. также Что такое виртуальный пакет?, раздел 6.8).

В настоящее время все управляющие файлы можно найти в каталоге /var/lib/dpkg/info . Файлы, относящиеся к пакету foo имеют имя «foo» и расширения «preinst», «postinst» и т.д. Файл foo.list в этом каталоге содержит список всех файлов установленных пакетом foo . (Заметим, что местонахождение файлов определяется dpkg; вам не следует полагаться на указанный каталог).

6.7 Что такое Требуемый/Важный/Стандартный/Необязательный/Дополнительный (Required/Important/Standard/Optional/Extra) пакет?

Для каждого пакета Debian создателями дистрибутива определен приоритет (priority), в качестве помощи для управления пакетами. Приоритеты следующие:

Требуемый (Required): пакет, который необходим для правильного функционирования системы.

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

Важные (Important) пакеты содержат программы, которые должны иметься в любой Unix-подобной системе.

Без этих программ не смогут работать или не будут обладать полной функциональностью другие пакеты. Сюда НЕ относятся Emacs, X11, Tex или любое другое большое приложение. Это пакеты образующие базовую структуру.

Стандартные (Standard) пакеты являются стандартными для любой Linux системы, включая сравнительно небольшие, но не слишком ограниченные, системы работающие только в текстовом режиме.

Это то, что будет установлено по умолчанию, если пользователь не выберет чего-либо еще. Сюда не относятся многие большие приложения, но входят такие, как Emacs и ограниченное подмножество TeX и LaTeX.

Необязательные (Optional) пакеты содержат все то, что вы, как правило, можете захотеть установить, если не вполне осознаете свои потребности.

Сюда входят X11, полный дистрибутив TeX, и множество других приложений.

Дополнительные (Extra): пакеты, которые либо конфликтуют с другими пакетами, имеющими более высокий приоритет, и применимые только тогда, когда вы знаете, что это такое, либо имеющие специализированные требования, которые делают их неподходящими для раздела «Optional».

6.8 Что такое виртуальный пакет?

Виртуальный пакет — это общее имя, применимое к любому из группы пакетов, все из которых обеспечивают выполнение какой либо функции. Например, программы tin и trn , обе являются программами для чтения новостей и должны удовлетворять зависимость программы, которая требует наличия в системе программы чтения новостей, для своей работы. Поэтому обе предоставляют «виртуальный пакет», называемый news-reader .

Аналогично, smail и sendmail обеспечивают функции почтового транспортного агента. Поэтому они предоставляют виртуальный пакет «mail transport agent». Если один из них установлен, то любая программа, зависящая от пакета mail-transport-agent , будет удовлетворена существованием данного виртуального пакета.

Кроме того, если в системе установлено более одного пакета, предоставляющего определенный виртуальный пакет, то Debian обеспечивает системного администратора механизмом, позволяющим определить один из этих пакетов предпочтительным. Для этого имеется команда update-alternatives , описанная далее в Некоторым пользователям нравится mawk, другим — gawk; некоторым — vim, другим — elvis; некоторым — trn, другим — tin; как осуществялется поддержка предпочтений в Debian?, раздел 10.10.

6.9 Что подразумевают говоря, что пакет Зависит/Рекомендует/Предполагает/Конфликтует/Заменяет/Предоставляет (Depends/Recommends/Suggests/Conflicts/Replaces/Provides) другой пакет?

В системе пакетов Debian введено понятие «зависимости» между пакетами, которое показывает насколько правильная работа Программы А зависит от существования Программы В на данной системе:

Пакет A зависит (depends) от пакета B, если B абсолютно необходим для работы A. В некоторых случаях, A не просто зависит от B, но дополнительно требует определенную версию B. В этом случае, обычно, накладывается требование, чтобы версия B была не ниже заданной.

Пакет A рекомендует (recommends) установку Пакета B, если сопровождающий пакета считает, что большинство пользователей не захотят пользоваться A не имея функциональности, предоставляемой пакетом B.

Пакет A поддерживает (suggests) Пакет B, если B содержит файлы относящиеся (и обычно расширяющие их) к функциям выполняемым пакетом A.

Пакет A конфликтует (conflicts) с Пакетом B, когда A не может работать, если установлен пакет B. Наиболее часто, конфликты возникают в случаях, когда A содержит файлы, заменяющие аналогичные, но содержащиеся в B. «Конфликты» часто сочетаются с «заменой».

Пакет A заменяет (replaces) пакет B, когда файлы установленные пакетом B удаляются и (в некоторых случаях) замещаются файлами пакета A.

Пакет A предоставляет (provides) Пакет B, когда все файлы и функциональность B обеспечиваются A.

Более подробная информация об использовании этих терминов может быть найдена в Руководстве по пакетам (Packaging manual) и в Руководстве по политике (Policy manual).

6.10 Что означает слово Pre-Depends (Пред-Зависимости)?

«Pre-Depends» это специальная форма зависимости. Большинство пакетов будут извлечены dpkg из архивных файлов независимо от того, существуют ли файлы от которых они зависят или нет. Проще говоря, dpkg извлекает файлы пакета из архива и помещает их на положенные места. Если пакет зависит от существования других пакетов, то dpkg откажется завершать установку (выполняя конфигурацию) до установки необходимых пакетов.

Однако, для некоторых пакетов, dpkg откажется даже распаковывать файлы до разрешения зависимостей. Такие пакеты указывают, что они «Pre-depend» от наличия других пакетов. Проект Debian обеспечивает механизм для безопасного обновления системы с формата a.out на формат ELF , где критичен порядок, в котором пакеты будут распакованы. Существуют и другие ситуации, когда может применяться этот метод.

Более подробная информация может быть найдена в Руководстве по пакетам.

6.11 Что означают слова неизвестно/установить/удалить/очистить/удерживать (unknown/install/remove/purge/hold) в статусе пакета?

Эти флаги определяют, что пользователь хочет сделать с пакетом (что определяется либо действиями пользователя при работе в разделе «Выбор» («Select») программы dselect , либо непосредственными обращениями пользователя к dpkg ).

неизвестно (unknown) — пользователь никогда не проявлял интереса к пакету.

установить (install) — пользователь хочет, чтобы пакет был установлен или обновлен.

удалить (remove) — пользователь хочет, чтобы пакет был удален, но не хочет удалять какие-либо из его файлов конфигурации.

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

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

6.12 Как я могу перевести пакет в удерживаемое (hold) состояние?

Есть два пути, которыми можно перевести пакет в удерживаемое состояние — при помощи dpkg или dselect.

С dpkg, вы просто экспортируете список выбранных пакетов:

Затем редактируете полученный файл selections.txt , заменяете строку, содержащую выбранный вами для удерживания пакет, напр. libc6 , с:

Сохраняете файл и загружаете его в базу данных dpkg:

C dselect, вы просто переходите в меню Выбор (Select), находите нужный пакет и нажимаете клавишу ‘=’ (или ‘H’). Изменения вступят в силу сразу же после вашего выхода из режима Выбор.

6.13 Как я могу установить пакет исходных текстов?

Пакеты исходных текстов Debian не могут быть «установлены», они просто распаковываются в том каталоге, в котором вы хотите собрать двоичный пакет. Исходные пакеты располагаются в каталоге source , и вы можете либо загрузить их вручную, либо воспользовавться командой:

(см. страницу руководства apt-get(8) ).

6.14 Как я могу построить двоичный пакет из исходного?

Вам необходимы foo_*.dsc, foo_*.tar.gz и foo_*.diff.gz файлы для компиляции исходного текста (для родных пакетов Debian файла .diff.gz может не быть).

Если у вас есть эти файлы и установлен пакет dpkg-dev , то следующая команда:

извлечет пакет в каталог foo-version .

Если вы хотите скомпилировать пакет, то перейдите в каталог foo-version и выполните команду

для компиляции программы, затем

как пользователь root, для сборки пакета, и затем

для установки пакета.

6.15 Как мне самому создать пакет Debian?

Детальное описание этого процесса содержится в «Руководстве начинающего разработчика Debian», доступном в пакете maint-guide-ru , или ftp://ftp.debian.org/debian/doc/package-developer/maint-guide.html.tar.gz .

Sysadminium

На этом уроке рассмотрим пакетные менеджеры apt и apt-get. Которые используются для работы с пакетами приложений в Linux.

Пакетные менеджеры apt

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

apt-get — используется для установки, удаления, обновления пакетов;
apt-cache — используется для получения информации о пакетах;
apt-mark — используется для установок различных меток на пакеты. Например, можно, поставив метку, запретить пакету обновляться;
apt — утилита основанная на apt-get и apt-cache. Она является более удобной и информативной. В процессе установки пакета, обновления системы или удаления пакета показывает “Прогресс бар”. В некоторых случаях выводит больше информации.

Работа с пакетами это административное действие, поэтому вам придётся работать под пользователем root или использовать sudo. Я в примерах буду использовать sudo. Примеры одинаково выполняются и в Debian и в Ubuntu.

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

apt — сам пакетный менеджер;
install — под-команда установки пакета;
–reinstall — опция переустановки;
apache2 — имя пакета.

Обновление системы

Обновление кэша пакетов

В Debian и Ubuntu прежде чем обновлять систему, нужно выяснить, какие обновления доступны в репозиториях. Это так называемое обновление кэша пакетов. Выполняется оно с помощью команды apt-get update или apt update. Пример:

При этом команда apt update дополнительно покажет количество пакетов, которые можно обновить и команду с помощью которой можно посмотреть список таких пакетов.

Получаем список возможных обновлений

Если есть пакеты, которые можно обновить, то мы можем посмотреть их с помощью команды apt list –upgradable, а опция -a выводит больше информации. С помощью apt-get это проделать невозможно.

Обновление системы (без возможности удаления пакетов)

Перед обновлением расскажу про зависимости пакетов. Работа некоторых приложений зависит от других приложений или библиотек. Поэтому почти каждый пакет имеет список зависимостей других пакетов. Обычно вручную с зависимостями не работают. Просто пакетные менеджеры (apt или apt-get) при установке определённого пакета также устанавливают пакеты от которых зависит этот пакет.

Точно также и при обновлении. Если приложение после обновления начало зависеть от других библиотек, то их тоже нужно установить или обновить.

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

Без возможности удаления пакетов вы можете выполнить обновление с помощью команд apt-get upgrade и apt upgrade. Например:

Обновление системы (с возможностью удаления пакетов)

Если вы все-таки хотите обновить пакеты и вас не пугает удаление некоторых пакетов, то выполните следующие команды: apt-get dist-upgrade или apt dist-upgrade. Но это более рискованно, так что обратите особое внимание на то, какие пакеты будут удалены. Ведь удаление некоторых пакетов может просто сломать вашу систему. Пример:

Получение информации о пакетах из репозиториев

Список пакетов в репозиториях

Чтобы получить список пакетов в репозиториях можно выполнить apt list. Так как это не административное действие, то можно не использовать sudo. Например:

Кстати, утилита apt-get это выполнить не может.

Поиск пакета по ключевому слову

Если мы примерно знаем название приложения, которое нам нужно, то можем попытаться найти пакет используя ключевое слово. При этом поиск идет не только по названию пакетов, но и по его содержимому. Такой поиск выполняется с помощью команд apt-cache search или apt search .

Пример (так как вывод может быть большим, то я использую less):

Смотрим информацию о пакете

Зная имя пакета, можем посмотреть информацию о нём с помощью команд apt-cache show или apt show .

Пример (так как вывод может быть большим, то я использую less):

Поиск зависимостей

Зависимости можно посмотреть в информации о пакете с помощью уже рассмотренных команд apt-cache show или apt show . Но для этого есть ещё одна команда: apt-cache depends или apt depends . Например:

Работа с отдельными пакетами

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

Установить пакет из репозитория можно с помощью команд apt-get install или apt install . При этом установится пакет и его зависимости. Пример:

Удаление пакета без удаления конфигов

Чтобы удалить пакет обычно используют команды apt-get remove или apt remove . Но эти команды удалят только само приложение, не удалив его конфиги. Пример:

Удаление пакета вместе с конфигами

А чтобы удалить приложение вместе с его конфигами используйте команды apt-get purge или apt purge , например:

Переустановка пакета

Для переустановки используйте команды apt-get install –reinstall или apt install –reinstall .

Обновление отдельного приложения

Если нам нужно обновить не всю систему а отдельный пакет, то тут нужно использовать знакомую команду apt-get install или apt install . При этом, если пакета нет в системе то он установится, а если есть то обновится. Пример:

Скачивание пакета без установки

Если вам просто нужно скачать пакет, а не устанавливать его в систему, то используйте команду apt-get download или apt download . Например:

При этом зависимости скачиваться не будут.

Заморозка пакета

Если вы хотите чтобы система больше не обновляла какой-то отдельный пакет то выполните apt-mark hold , например:

К сожалению с помощью apt это проделать невозможно.

Исправление проблем с пакетами

Исправление ошибок с зависимостями

Если в процессе установки некоторого пакета или при обновлении всей системы вы столкнётесь с проблемой с зависимостями. То можете воспользоваться командами apt-get -f install или apt -f install. Эти команды пытаются решить проблемы с зависимостями путём удаления или установки новых пакетов.

Только внимательно смотрите на список удаляемых пакетов!

Очистка системы от ненужных пакетов

Удаление ненужных пакетов

Когда мы устанавливаем пакет то устанавливаются и его зависимости. А при удалении пакета зависимости остаются и больше не используются. Чтобы удалить подобные пакеты, которые установились, но больше не нужны в системе применяются команды apt-get autoremove или apt autoremove. Например:

Очистка кэша

При установке какого-нибудь пакета, он вначале скачивается в каталог /var/cache/apt/archives/, а затем устанавливается в систему. Эти установочные файлы тоже можно удалять, освобождая место на диске. Для этого используйте команды apt-get clean или apt clean, например

Мягкая очистка кэша

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

Посмотрим на корову

А еще с помощью apt-get и apt мы можем посмотреть на корову:

Мы узнали множество команд с помощью которых можем устанавливать и удалять пакеты в систему, а также обновлять её. И проделывать другие вещи.

А также мы узнали что перед установкой deb пакеты скачиваются в каталог /var/cache/apt/archives/. И у пакетов есть зависимости, которые apt или apt-get определяет и автоматически устанавливает.

В дистрибутиве Linux под названием Gentoo, несмотря на небольшую распространенность, также имеется собственный инструмент для управления пакетами. Называется такая программа – Portage. Она позволяет собирать комплект из исходников прямо во время установки приложений. В набор функций входит возможность настроить флаги компиляции, собрать пакет под процессор и т.д.

PORTAGE

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

Выводы

Менеджеры пакетов, в зависимости от релиза Linux, могут обладать уникальными возможностями, как в случае Gentoo. Но основной их задачей остается управление базовыми функциями – установкой, обновлением, удалением пакетов. Поэтому различия в перечне настроек касаются больше любителей поэкспериментировать.

Беда Linux: зависимости

По мнению Ли Шлесингера (Lee Schlesinger), зависимости являются настоящим бичом современного Linux и замедляют рост его популярности. Они превращают установку новой программы в непростую задачу, тогда как в Windows все решается «за один клик». Ли Шлесингера предлагает способы борьбы с этой проблемой.

Re: Беда Linux: зависимости

>Ли Шлесингера предлагает способы борьбы с этой проблемой.

Задолго до него это сделал Патрик Волькердинг, создав Slackware ;)))

Re: Беда Linux: зависимости

тогда как в Windows все решается «за один клик»

Re: Re: Беда Linux: зависимости

Был когда-то в старых версиях Выни. Сейчас такого нет

Re: Беда Linux: зависимости

apt-get install и никаких проблем

Re: Беда Linux: зависимости

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

Re: Беда Linux: зависимости

>>»за один клик»
Нуууу не всегда. Иногда доходит до клика молотком или головой.

Re: Беда Linux: зависимости

только потом выкликивать затрхаешся

Re: Беда Linux: зависимости

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

Re: Беда Linux: зависимости

Упоминание о Slackware Linux здесь не уместно, ибо отсутствие поддержки зависимостей в менеджере пакетов проблему зависимостей не решает. Зато это небольшой и простой дистрибутив в котором пакеты не разбиваются на множество «подпакетов» (в отличие от Mandrake Linux и Debian GNU/Linux). Однако введение поддержки зависимостей не помешала бы, как и расширения гаммы пакетов. PS. Сам я являюсь пользователем и Slackware, и Mandrake, и Debian (Knoppix).

Re: Re: Беда Linux: зависимости

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

Re: Беда Linux: зависимости

>Был когда-то в старых версиях Выни. Сейчас такого нет

Что значит нет? Чтобы выяснить под rpm-based дистрибутивом, какой пакет принес мне файл или либу на которые я смотрю, я делаю rpm -qf «имя файла». А как Вы это делаете под виндой? Реально, когда приходится работать под виндой мне не хватает именно пакэдж менеджера, остальные неудобства еще можно было бы терпеть. Опять же, под линуксом невозможно случайно снести пакет, который используется другими пакетами. А как под виндой выяснить, какие проги испотзуют данный файл? Так что через #опу это как раз в винде, где нет не то что apt’a, а даже аналога rpm/dpkg.

Re: Увеличить скорость путем пересбора всего из сырцов? Не в этой жизни!

Просто под виндой такой необходимости не возникает

Re: Re: Re: Беда Linux: зависимости

Уважемый, а Вы вообще пользовались ли когда нибудь «слакой»? Я думаю, что в помойку можно превратить любую систему: от Slackware до RedHat с Debianom и *BSD.

Re: Re: Re: Re: Беда Linux: зависимости

> Уважемый, а Вы вообще пользовались ли когда нибудь «слакой»?

Пользовался. Больше нет такого желания.

> Я думаю, что в помойку можно превратить любую систему: от Slackware до RedHat с Debianom и *BSD.

Разумеется. Но проблема в том, что слаку не превратить в помойку практически нельзя.

Re: Re: Re: Re: Беда Linux: зависимости

Re: Re: Re: Re: Re: Беда Linux: зависимости

Не пойму с чего Вы взяли, что «слака» — это обязательно помойка.

Re: Re: Беда Linux: зависимости

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

В слаке возможно все.

Re: Re: Увеличить скорость путем пересбора всего из сырцов? Не в этой жизни!

Давно вы вычищали систему у кого-нибудь из знакомых? Мне вот периодически приходится. Так вот без rpm/dpkg очень, очень и очень плохо. Это и отсутствие нормального shell (хотя тут есть cygwin) самые главные неудобства Windows.

Так, ради примера — используем Debian Unstable (хочется имет всё время новые программы), каждый день устанавливается/обновляется штук 5 минимум. Система жива и живёт достаточно долго — с июня. Можно ли так с Windows? НЕТ! Т.к. главная заповедь нормальной эксплуатации Win — поставить всё что нужно или может понадобиться и не менять больше ничего никогда. Только в этом случае она живёт годами. А debian — и в моём режиме не портится. Разница есть?

Re: Re: Re: Беда Linux: зависимости

Снести пакет можно в любой системе (rpm —force на RedHat-основанных). При это ни кто не гарантирует, что зависимости настроены достаточно правильно, чтобы «случайно» не получилось. Ну а в общем вся дискуссия свелась к «обкакиванию» «слаки» и иже с ними.

Re: Re: Re: Re: Re: Беда Linux: зависимости

4anonymous (*) (22.10.2003 13:00:16)

>> Уважемый, а Вы вообще пользовались ли когда нибудь «слакой»?

> Пользовался. Больше нет такого желания.

Это хорошо. Зачем оно тебе? Зачем нам, такие, как ты?

>> Я думаю, что в помойку можно превратить любую систему: от Slackware до RedHat с Debian`ом и *BSD.

> Разумеется. Но проблема в том, что слаку не превратить в помойку практически нельзя.

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

Я, конечно, понимаю, что давит так, что крышу сносит.

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

Re: Re: Re: Re: Беда Linux: зависимости

Так ведь тема-то совершенно пустая. Достаточно очевидно, что человек не прав. И всё тут.

Re: Re: Re: Re: Re: Беда Linux: зависимости

да, видать плохи дела microsoft.

Re: Re: Re: Re: Re: Беда Linux: зависимости

>>Так ведь тема-то совершенно пустая. Достаточно очевидно, что человек
>>не прав. И всё тут.
Ну это понятно.
Давайте еще разберемся с группой слака всегда прав.

Re: Re: Беда Linux: зависимости

alt-x (*) (22.10.2003 12:43:09) А зачем выяснять какая прога использует этот файл?

Когда программу деинсталлируешь — все что нужно подчищается автоматом. Если программа не требует инсталяции — то ее просто вытираешь вместе с директорией и все — никакого хлама! :)))

Re: Re: Re: Re: Re: Re: Беда Linux: зависимости

anonymous (*) (22.10.2003 13:45:59) Чем плохи?

Re: Re: Re: Re: Re: Re: Беда Linux: зависимости

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

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

Лично мне значительно проще разобраться где что лежит в /cdrom/slakware/, чем в /RedHat/RPMS или запустив гуевый rpm-tool, не помню как его правильно называть.

Re: Re: Re: Беда Linux: зависимости

> Когда программу деинсталлируешь — все что нужно подчищается автоматом.

Загляни в *:Program Files, вспомни, какие программы у тебя стояли, а какие ты уже удалил. ты будешь весьма удивлен.

Аналогично, относительно c:win*system32*.* (dll,vxd. )

Re: Re: Re: Беда Linux: зависимости

> Когда программу деинсталлируешь — все что нужно подчищается автоматом.

Ты в этом уверен? Наивный win-user.

А в реестр заглядывать на пробовал?

Re: Re: Re: Увеличить скорость путем пересбора всего из сырцов? Не в этой жизни!

> . Можно ли так с Windows? НЕТ!

Можно. 2000 prof живет с октября 2001 года — тогда дали новую машинку. Периодически сносятся и ставятся программы. Системе хоть бы хны.

Про дебиан. Возникли проблемы с инсталляцией gnome 2.4. Я его поставил, конечно, с указанием опций в apt-get install. Только почему-то при этом был снесен начисто кде. Наверное, я забыл прочитать пять томов манов на тему apt. rpm несколько проще

Re: Re: Re: Re: Re: Re: Re: Беда Linux: зависимости

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

Re: Re: Re: Re: Беда Linux: зависимости

>>> Когда программу деинсталлируешь — все что нужно подчищается автоматом.

>> Ты в этом уверен? Наивный win-user.

> А в реестр заглядывать на пробовал?

Лучше в реестр его не посылать, а то еще удалит чего-нибудь ненароком. а оно не восстанавливается, ведь.

Re: Re: Re: Re: Re: Беда Linux: зависимости

> а оно не восстанавливается, ведь.

тогда пускай и в штаны не заглядывает, мало ли что

Re: Re: Re: Re: Увеличить скорость путем пересбора всего из сырцов? Не в этой жизни!

>>Наверное, я забыл прочитать пять томов манов на тему apt. rpm
Ну в реестре то Win все интуитивно понятно. Взял да потер немного. Все работает ?

Re: Re: Re: Re: Увеличить скорость путем пересбора всего из сырцов? Не в этой жизни!

> Про дебиан. Возникли проблемы с инсталляцией gnome 2.4. Я его поставил, конечно, с указанием опций в apt-get install. Только почему-то при этом был снесен начисто кде. Наверное, я забыл прочитать пять томов манов на тему apt. rpm несколько проще

Перед указанием опций рекомендуется ознакомиться с тем, что они делают.

Re: Увеличить скорость путем пересбора всего из сырцов? Не в этой жизни!

> Перед указанием опций рекомендуется ознакомиться с тем, что они делают.

Это у микрософта во всех инсталляторах «рекомандуется».

А в дебиане где? чтобы найти что рекомендуется, нужно петь томов манов скурить, а потом еще и пол-Linux-HOWTO

Re: Re: Re: Re: Re: Беда Linux: зависимости

>>Когда программу деинсталлируешь — все что нужно подчищается автоматом
Простой тест.
Ставишь демонстрашку любой программы.
Когда срок кончается сносишь.
Устанавливаешь заново и пользуйся на здровье.
Все просто.
Ато Linux Linux.

Re: Беда Linux: зависимости

emerge xxx ивсе дела

Re: Беда Linux: зависимости

Кстати по поводу что в Винде все просто. А пробовали установить прогу не в дефолтную папку? Сравнивали размер диска до инсталяции и после сноса? Заглядывали в regedit после сноса? (Хотя конечно половина — вина криворуких програмеров) Если там каждий день обновления ставить то через пол-года можно диск форматировать заново.

Так что что угодно только не MS-OS

Re: Re: Re: Re: Увеличить скорость путем пересбора всего из сырцов? Не в этой жизни!

Периодически — это 3 штуки в день? Я именно об этом писал. И потом, не наблюдается ли у вас некоего роста каталога c:winntsystem32?

Насчёт apt-get install — если работать с unstable то это действительно может возникнуть, но ведь програмка-то apt-get пишет, что собирается то-то удалить. Такие вещи возникают из-за того, что unstable постоянно модифицируется и иногда возникают конфликты зависимостей, которые обычно разрешаются на следующий день. Т.о. — либо нужно было подождать завтра, либо пользоваться не unstable, а stable.

Честно говоря, хотелось бы узнать ещё и комбинацию опций, которая применялась. Хотя и так ясно, что лучше не писать -y.

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

Re: Re: Увеличить скорость путем пересбора всего из сырцов? Не в этой жизни!

man apt-get — 9 страниц, если торопитесь можно ограничиться 2-мя верхними

Re: Re: Re: Re: Увеличить скорость путем пересбора всего из сырцов? Не в этой жизни!

>Про дебиан. Возникли проблемы с инсталляцией gnome 2.4. Я его поставил, конечно, с указанием опций в apt-get install. Только почему-то при этом был снесен начисто кде. Наверное, я забыл прочитать пять томов манов на тему apt

Наверное, ты KDE по-пьяни снёс, а на apt валишь.

Re: Re: Re: Re: Re: Увеличить скорость путем пересбора всего из сырцов? Не в этой жизни!

По поводу виндовозов — опять накипело.
Делал прогу — а-ля шабашка. Для админов компового
клуба. На самом деле — обвязка скриптов на Qt.
Так вот, они говорили, что интерейс непонятный и
не могли драг-ндропом машины таскать из неактивной
области в активную. Знаете как всё решилось? Установкой
виндовых цветов и стиля! И всё! Теперь, бл»#* всё понятно.

По поводу дебиана. Срабатывают виндовозные обезьяньи инстинкты:
давить next -> говорить Yes, Yes, Yes I understand it can be bad

Я на полном серьёзе — знакомый bash так снёс — не поленился такое
вот написать — и потом ругался на дебиан, который сломал его
систему )

Re: Re: Re: Re: Увеличить скорость путем пересбора всего из сырцов? Не в этой жизни!

> Про дебиан. Возникли проблемы с инсталляцией gnome 2.4.

в дебиане сейчас нет gnome 2.4 даже в unstable. есть только gnome 2.2. если ты ставил пакеты из какого-то «левого» репозитария, то должен знать, что делаешь. дебиан рулит. =)

Re: Re: Re: Re: Re: Увеличить скорость путем пересбора всего из сырцов? Не в этой жизни!

На самом деле инсталляция гнома требовала указать для apt-get версию через опцию -t (по-моему, что-то вроде 2.4) . Я и указал. Иначе он просто ставиться не хотел — полиси так и говорило, что ставить не буду. По какой причине — хез, лень было курить тома (в линуксе же все просто, само работает). После указания этой опции gnome поставился, но при этом был удален кде. Базовые либы остались, достаточные для работы кде-шных программ. Но сама оболочка, включая kdm была просто снесена.

Мне вообщем все равно, так как мне понадобился оракле клиент, а ставить его на линукс путем скачивания 3-х дисков сервера было влом.

Что такое зависимости в линукс

Менеджеры пакетов в Linux

Установка ПО (или пакетов) в дистрибутивах Linux происходит «централизованно», что удобно, но часто вызывает вопросы у новичков. И так, максимально доходчиво я постараюсь объяснить, почему всё не так как в Windows и зачем знать базовые команды консольного менеджера пакетов, если в любом современном дистрибутиве есть графический интерфейс.

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

При установке той или иной программы через пакетный менеджер видно, что вместе с пакетом самой программы, в систему устанавливается ещё куча всяких пакетов. Чем сложнее программа и чем «чище» ваша система, тем больше пакетов устанавливается в качестве «зависимостей». Зависимости – это системные библиотеки, а иногда и другие программы, необходимые для работы устанавливаемой программы. Каждый пакет в репозитории содержит файл-манифест, в котором указаны все зависимости. В Windows также, некоторые упакованные программы требуют наличия определённых компонентов в системе. Например, для игр необходимо наличие библиотек DirectX в каталоге «system32» и так далее. Это те же зависимости. Установщик программы видит их наличие и сообщит вам о их отсутствии, если не найдёт соответствующую запись в реестре. На самом деле, в Windows программы часто просто не запускаются или вылетают с ошибкой, но причина именно в отсутствии того или иного компонента. В Linux же пакет просто не будет установлен, если нет возможности соблюсти все зависимости. Разбором зависимостей и занимается пакетный менеджер. В идеале в репозиториях дистрибутива есть всё необходимое для соблюдения всех зависимостей всех пакетов. В этом заключается опасность использования сторонних репозиториев. Если информация о зависимостях в них устарела, или содержит ошибки, то использование пакетов из таких репозиториев может вызвать проблемы той или иной сложности. Имена пакетов, системных библиотек и их версии в разных дистрибутивах отличаются. Поэтому невозможно без плясок с бубном взять пакет из Ubuntu и установить его в OpenSUSE. Теоретически это можно сделать, пересобрав пакет и установив нужные зависимости, но такой пакет не будет обновляться, даже если не вызовет других проблем. Всегда нужно устанавливать пакеты именно для вашего дистрибутива и к другим способам прибегать только в случае крайней необходимости. Если ваш дистрибутив не содержит всего того, что вам нужно, то это серьёзный повод для смены дистрибутива.

Существует несколько пакетных менеджеров со своими плюсами и минусами, а также сам подход к зависимостям у большинства дистрибутив отличается. Кроме пакетов с ПО, существуют так называемые «мета-пакеты», которые содержат только инструкции по зависимостям. Мета-пакеты используются для установки комплексных решений в один клик. Например, мета-пакеты рабочих столов, когда установкой одного мета-пакета можно установить окружение рабочего стола и кучу прикладного ПО. Та же ситуация и с удалением. Рано или поздно вы захотите удалить неиспользуемое ПО, входящее в состав дистрибутива. И, в зависимости от дистрибутива, можете обнаружить, что удаление почтовой программы удаляет также мета-пакет рабочего стола, что помечает половину пакетов в вашей системе как «ненужные». Пакеты, установленные как зависимости, могут быть безболезненно удалены как в процессе удаления основного пакета, так и после. Беда в том, что мета-пакет рабочего стола был указан как жёсткая зависимость почтовой программы. Имеется в виду, что без рабочего стола она работать не будет. Но не учитывается, что рабочий стол без почтовой программы может работать без каких-либо проблем. В итоге, после невнимательного удаления чего-либо действительно ненужного, можно обнаружить, что система стала легче гигабайт на 5, но при этом загружается в чёрный экран и командную строку. Такой подход к зависимостям свойственен, например, Ubuntu, тогда как пакетный менеджер в Arch Linux помечает подобные зависимости как «необязательные», что избавляет пользователя от проблем, приведённых в пример выше, но требует от него определённых знаний. То есть, если утрировать, то рабочий стол без почтовой программы работает, но кому-то может понадобиться её функционал. Таким образом, пользователь должен знать какие необязательные зависимости ему нужны, а какие нет. Большинство же дистрибутивов решают это за пользователя, имея в зависимостях того или иного пакета максимальный набор компонентов «на все случаи жизни». Другими словами, чем меньше знаний требуется для использования дистрибутива, тем больше в нём «мусора». И чем больше опыта у пользователя, тем сложнее его «настольный» дистрибутив. По той же причине в мире существует огромное количество различных дистрибутивов, ориентированных на различную аудиторию. Но не всегда широта возможностей прямо пропорциональна сложности.

Исторически так сложилось, что большая часть пакетов в Linux зависит от наличия системных библиотек. По аналогии с директорией «system32» в Windows, в Linux есть директория «lib». Такой подход экономит место, когда одна и та же системная библиотека используется множеством программ, но он же делает пакеты одного дистрибутива непригодным для установки в другой. Кроме имён системных библиотек отличаются так же их версии, в зависимости от дистрибутива. Во многих пакетах в качестве зависимостей указаны не только сами библиотеки, но и их версии. По той же причине многие дистрибутивы не обновляют версии ПО в пределах жизненного цикла версии дистрибутива. Например, в Debian вы будете получать обновления безопасности, но версии практически всего ПО останутся неизменными. Таким образом ряд дистрибутивов поддерживает стабильность. Тот же подход можно видеть в корпоративных версиях Windows, когда весь функционал заморожен в пределах одной версии, и обновления содержат только исправления и патчи безопасности. Но в Windows это касается только компонентов ОС, тогда как всё остальное устанавливается и обновляется отдельно. В Linux же всё прикладное ПО распространяется централизованно, как и компоненты ОС. Теоретически новая версия определённой программы будет работать с текущей версией определённой системной библиотеки, так же, как и текущая версия программы с более новой библиотекой, но это не тестировалось на пререлизных стадиях дистрибутива. Всегда есть шанс, что что-то пойдёт не так. Поэтому в ряде дистрибутивов есть стадия так называемой «заморозки», когда перед релизом все версии ПО замораживаются и остаются неизменными на протяжении всего жизненного цикла версии дистрибутива. Такой подход даёт свои результаты. Если не использовать сомнительные сторонние репозитории в Debian, то она гораздо стабильнее даже корпоративных версий Windows. Некоторые дистрибутивы могут сочетать в себе стабильность и инновации. То есть, они устанавливают рань между новизной ПО и его стабильностью на более приемлемой для широкого круга пользователей позиции. Роллинг-дистрибутивы так же могут быть стабильными, если разработчики и тестировщики приложили к этому достаточно усилий.

Понятно, что «пакетно-зависимый» подход не всегда оправдывает себя. Попытки унификации пакетов ПО для Linux были всегда. Две самые удачные и современные системы – это Snap от Canonical и Flatpak, которая разрабатывается сообществом. Обе системы не идеальны, но позволяют решить две самые основные задачи: унификация и интеграция. В отличии от более ранних реализаций, установленное таким образом ПО смотрится нативно и интегрировано в систему (ОС знает, что оно установлено, присутствуют все привычные меню, ярлыки и прочее). Основным плюсом является то, что подобный пакет содержит все необходимые зависимости и работает на любом дистрибутиве, способом работать с этой системой пакетов. Разработчикам не нужно разбирать зависимости каждого дистрибутива при создании пакета. Нужно лишь учитывать специфику самой системы Snap или Flatpak. А то, как система в целом работает в дистрибутиве – это дело разработчиков дистрибутива. Как уже было сказано, Snap и Flatpak не идеальны. По ряду причин ПО не всегда выглядит нативно и не всегда учитывается всё возможное. Это зависит как от самих этих систем, так и от интеграции системы на стороне дистрибутива. Но обе системы развиваются и, на мой взгляд, это шаг в правильном направлении, хотя обе системы часто критикуются. В основном критика относится к проприетарной природе серверной части Snap и тому факту, что в Ubuntu, при установке ПО через графический интерфейс, приоритет отдаётся пакетам Snap. Так же критикуется «Windows-подход» при распространении ПО подобным способом. Последнее относится, в основном, к размеру и нагрузке. Размер этих пакетов значительно выше традиционных пакетов, так как каждый пакет содержит все необходимые зависимости локально, и их наличие или отсутствие в системе во внимание не берётся. Но при объёмах современных носителей информации лишний десяток гигабайт менее важен, чем унификация пакетов в Linux.

Для управления пакетами Snap и Flatpak используются их собственные пакетные менеджеры, но многие «традиционные» пакетные менеджеры имеют плагины для работы с этими пакетами.

И так, если с зависимостями и различиями в дистрибутивах всё более или менее ясно, то при чём тут командная строка? Дело всё в той же централизованной системе. При обновлении пакетов, в системе часто обновляются и компоненты рабочего стола, и сам пакетный менеджер. Чем меньше компонентов задействовано в процессе обновления, тем меньше шансов на то, что что-то пойдёт не так. Графический интерфейс для всех пакетных менеджеров – это всего лишь «надстройка». Если установка и удаление пакетов обычно проходит гладко, то при использовании консоли у вас больше возможностей решить ту, или иную проблему, возникшую во время обновления. Особенно это актуально в роллинг-дистрибутивах, где со временем обновляется не только само ПО, но и список его зависимостей. Графический интерфейс может повиснуть при обновлении его компонентов, консоль же менее зависит от окружения рабочего стола, даже если является его частью. Не важно как вы обновляете Snap-пакеты или Flatpak-пакеты, так как они не затрагивают систему, но в остальных случаях обновляться через консоль безопаснее.
В Сети часто можно найти инструкции по сборке того или иного из исходного кода и последующей установке (команда make install), но это плохая идея в пакетных дистрибутивах, где пакетный менеджер – основной и часто единственный инструмент контроля и управления программным обеспечением. Даже в Gentoo, где всё собирается из исходников, есть свои инструменты контроля. В пакетных же дистрибутивах правильным будет собрать пакет и установить его с помощью пакетного менеджера. Исключение можно сделать для чего-то локального, установленного в один отдельный каталог с правами пользователя. Ручное «размазывание» библиотек по системным разделам – плохая идея, так как рано или поздно возникнут проблемы.

И так, резюмируя всё вышесказанное… Пакетные менеджеры в Linux существуют не только для удобства. Они ведут учёт ПО и обеспечивают правильность его установки, от чего зависит стабильность работы как самого ПО, так и операционной системы в целом. Установка ПО другими способами возможна, но с рядом оговорок. На самом деле, подобный подход кажется странным только тем, кто много лет просидел на Windows. В Windows так же есть эксперименты с пакетными менеджерами, но проприетарная модель как самой ОС, так и большей части программ под неё, не позволяет добиться той же слаженности, что мы видим в операционных системах на ядре Linux.