Что такое пакет линукс
Эволюция менеджеров пакетов в Linux
Оригинал: The evolution of package managers
Автор: Steve Ovens
Дата публикации: 26 июля 2018 года
Перевод: А. Кривошей
Дата перевода: ноябрь 2018 г.
Менеджеры пакетов играют важную роль в системе управления программным обеспечением Linux. В данной статье производится сравнение наиболее популярных игроков на этом рынке.
Каждое компьютеризированное устройство использует для выполнения своих задач некоторую форму программного обеспечения. Давным давно продукты программного обеспечения строго тестировались на наличие ошибок и других дефектов. В течение последнего десятилетия программное обеспечение распространяется через Интернет, подразумевая, чтобы любые найденные ошибки будут исправлены путем выпуска новых версий программного обеспечения. В некоторых случаях каждое отдельное приложение имеет свой собственный модуль обновления. В других случаях пользователю предоставляется возможность выяснить, как получить и обновить программное обеспечение.
В Linux давно введена практика создания централизованного хранилища, где пользователи могут находить и устанавливать программное обеспечение. В этой статье я расскажу об истории установки программ в Linux и о том, как постоянно обновляются современные операционные системы.
Как устанавливались программы в Linux до появления менеджеров пакетов?
Как только файл Makefile создан, вы должны продолжить, запустив выполнение команды make (эта команда предоставляется любым компилятором, который вы используете). Команда make имеет несколько параметров, называемых make flags, которые помогают оптимизировать результирующие двоичные файлы для вашей системы. Раньше это было очень важно, потому что аппаратное обеспечение изо всех сил старалось не отставать от современных требований к программному обеспечению. Сегодня варианты компиляции могут быть гораздо более универсальными, поскольку большинство аппаратных средств более чем подходит для современного программного обеспечения.
Наконец, после того, как процесс make завершен, вам нужно будет выполнить make install (или sudo make install), чтобы фактически установить программное обеспечение. Как вы можете себе представить, делать это для каждой отдельной программы было трудоемким и утомительным процессом, не говоря уже о том, что обновление программного обеспечения было сложным и потенциально очень рискованным процессом.
Что такое пакет?
Пакеты были изобретены для борьбы с этими сложностями. Пакеты собирают несколько файлов вместе в один файл архива для упрощения переносимости и хранения или просто сжимают файлы для уменьшения объема. Бинарные файлы, включенные в пакет, предварительно скомпилированы в соответствии со стандартными значениями по умолчанию, выбранными разработчиком. Пакеты также содержат метаданные, такие как имя программы, описание ее назначения, номер версии и список зависимостей, необходимых для правильной работы программы.
Несколько проектов Linux разработали свои собственные форматы пакетов. Некоторые из наиболее часто используемых форматов пакетов:
.deb: Этот формат пакета используется Debian, Ubuntu, Linux Mint и многими другими их производными. Это был первый разработанный тип пакета.
.rpm: Этот формат пакета первоначально назывался Red Hat Package Manager. Он используется Red Hat, Fedora, SUSE и другими меньшими дистрибутивами на их базе.
.tar.xz: это просто архив с файлами программы, это формат, который использует Arch Linux.
Хотя сами пакеты напрямую не управляют зависимостями, они представляют собой огромный шаг вперед в управлении программным обеспечением Linux.
Что такое репозиторий программного обеспечения?
Несколько лет назад, до распространения смартфонов, идея создания репозитория программного обеспечения была сложной для многих пользователей, если они не были вовлечены в экосистему Linux. По сей день большинство пользователей Windows по-прежнему используют веб-браузер для поиска и установки нового программного обеспечения. Тем не менее, те, у кого есть смартфоны, привыкли к идее «магазина» программного обеспечения. То, как пользователи смартфонов получают программы, и как работают менеджеры пакетов, не отличается друг от друга. Хотя было несколько попыток создать привлекательный интерфейс для репозиториев программного обеспечения, подавляющее большинство пользователей Linux по-прежнему используют для установки пакетов командную строку. Репозитории программного обеспечения представляют собой централизованный список всех доступных программ для любого репозитория, подключенного к системе. Ниже приведены некоторые примеры поиска репозитория для заданного пакета (обратите внимание, что они были усечены для краткости):
Arch Linux с использованием aurman
Ubuntu с использованием APT
Наиболее распространенные менеджеры пакетов.
Как показано в приведенном выше выводе, для взаимодействия с репозиториями программного обеспечения используются менеджеры пакетов. Ниже приведен краткий обзор некоторых из наиболее известных менеджеров пакетов.
Менеджеры пакетов на основе RPM
Обновление систем на основе RPM, особенно тех, которые основаны на технологиях Red Hat, имеет очень интересную историю. Фактически, текущие версии yum (для корпоративных дистрибутивов) и DNF (для сообщества) для обеспечения их текущей функциональности объединяют несколько проектов с открытым исходным кодом.
Первоначально Red Hat использовал диспетчер пакетов RPM (Red Hat Package Manager), который по-прежнему используется и сегодня. Однако его основное назначение заключается в установке пакетов RPM, которые находятся локально на вашем компьютере, а не для поиска репозиториев программного обеспечения. Для информирования пользователей об обновлениях пакетов был создан менеджер пакетов с именем up2date, он позволяет искать удаленные репозитории и легко устанавливать зависимости. В то же время, некоторые члены сообщества считали, что у up2date были некоторые существенные недостатки.
Нынешняя реализация yum произошла из усилий различных частей сообщества. Yellowdog Updater (YUP) был разработан в 1999-2001 годах людьми из Terra Soft Solutions в качестве базового механизма для графического установщика Yellow Dog Linux. Людям из Duke University понравилась идея YUP и они решили улучшить его. Они создали Yellowdog Updater, Modified (yum), который в конечном итоге был адаптирован для управления системами Red Hat Linux в университете. Популярность Yum росла, и к 2005 году он, по различным оценкам, использовался более чем половиной рынка Linux. Сегодня почти во всех дистрибутивах Linux, использующих RPM, для управления пакетами используется yum (с несколькими заметными исключениями).
Работа с yum
Это один из моих локальных репозиториев, что объясняет, почему проверка GPG отключена. Если бы эта проверка была включена, каждый пакет должен быть подписан криптографическим ключом, и соответствующий ключ должен быть импортирован в систему, получающую обновления. Поскольку я сам поддерживаю этот репозиторий, я доверяю пакетам и не буду их подписывать.
Установка нового пакета так же проста. Сначала найдите имя пакета с помощью поиска yum:
Бывают случаи, когда вы не знаете имя пакета, но знаете имя утилиты. Например, предположим, что вы ищете утилиту updateb, которая создает/обновляет базу данных, используемую командой locate. Попытка установить updatedb возвращает следующие результаты:
Вы можете узнать, из какого пакета работает утилита:
Причина, по которой я использовал звездочку перед командой, заключается в том, что yum whatprovides использует путь к файлу, чтобы найти совпадение. Поскольку я не был уверен, где находится файл, я использовал звездочку, чтобы указать любой путь.
Есть, конечно, еще много вариантов использования для yum. Я рекомендую вам просмотреть man-страницу yum для изучения дополнительных параметров.
Работа с Zypper
Использование Zypper очень похоже на использование yum. Для поиска, обновления, установки или удаления пакета просто используйте следующие команды:
Некоторые существенные различия имеются в том, как с помощью zypper в систему добавляются репозитории. В отличие от описанных выше менеджеров пакетов, zypper добавляет репозитории, используя сам менеджер пакетов. Наиболее распространенным способом является URL-адрес, но zypper также поддерживает импорт из файлов репо.
Аналогично вы можете удалять репозитории:
Используйте команду zypper repos, чтобы узнать статус репозиториев в вашей системе:
zypper даже имеет аналогичную способность определять, какой пакет содержит заданные файлы. В отличие от YUM, в команде используется дефис (хотя этот метод поиска устарел):
Как и в случае с YUM и DNF, Zypper имеет гораздо более богатый набор функций, чем мы здесь рассказали. Ознакомьтесь с официальной документацией для получения более подробной информации.
Менеджеры пакетов на базе Debian
Это создаст файл spideroakone.list в /etc/apt/sources.list.d. Очевидно, эти строки меняются в зависимости от добавляемого репозитория. Если вы добавляете Personal Package Archive (PPA), вы можете сделать это следующим образом:
Примечание: Debian не поддерживает PPA нативно.
После добавления репозитория система на базе Debian должна быть уведомлена о том, что существует новое место для поиска пакетов. Это делается с помощью команды apt-get update:
Теперь новый репозиторий добавлен и обновлен, вы можете искать в нем пакеты с помощью команды apt-cache:
Для установки kate просто запустите соответствующую команду установки:
Для удаления пакета используйте команду apt-get remove:
Когда дело доходит до обнаружения пакетов, APT не предоставляет никаких функций, похожих на yum. Есть несколько способов получить эту информацию, если вы пытаетесь найти, откуда появился конкретный файл на диске.
Проблема с поиском apt-file заключается в том, что он, в отличие от yum whatprovides, слишком многословный, если вы не знаете точного пути, и он автоматически добавляет поиск подходящих символов, чтобы вы получили результаты по всему со словом kate в нем:
Большинство из этих примеров использовали apt-get. Обратите внимание, что большинство текущих руководств для Ubuntu специально используют просто apt. Команда apt была разработана для реализации только наиболее часто используемых команд в арсенале APT. Поскольку функциональность разделена между apt-get, apt-cache и другими командами, apt пытается объединить их в одну команду. Он также добавил некоторые тонкости, такие как раскраска, индикаторы выполнения и т.д. Большинство упомянутых выше команд можно заменить apt, но не все дистрибутивы на основе Debian поддерживают apt по умолчанию, поэтому вам может потребоваться установить дополнительные пакеты.
Менеджеры пакетов на базе Arch
Эта система привела к созданию Arch User Repository (AUR), который представляет собой репозиторий, основанный сообществом и содержащий файлы PKGBUILD и поддерживающий патчи или скрипты. Это позволяет использовать практически бесконечное количество программ в Arch. Очевидным преимуществом этой системы является то, что если пользователь (или майнтайнер) хочет сделать программное обеспечение доступным для общественности, им не нужно проходить официальные каналы, чтобы разместить его в основных репозиториях. Недостатком является то, что он зависит от сообщества, подобного Docker Hub, пакетам Canonical Snap или другим аналогичным механизмам. Существует множество AUR-специфичных менеджеров пакетов, которые можно использовать для загрузки, компиляции и установки из файлов PKGBUILD в AUR (мы рассмотрим их позже).
Работа с pacman и официальными репозиториями
В pacman.conf можно указать определенный URL. Эта функциональность может быть использована для того, чтобы все пакеты получались с определенного момента времени. Если, например, у пакета есть ошибка, которая сильно влияет на ваши задачи, и он имеет несколько зависимостей, вы можете вернуться к определенному моменту времени, добавив в свой файл pacman.conf определенный URL-адрес, а затем выполнив команды для даунгрейда системы:
Подобно системам на базе Debian, Arch не обновляет информацию о локальном репозитории, пока вы не скажете ему об этом. Вы можете обновить базу данных пакета, выполнив следующую команду:
Pacman, на мой взгляд, предлагает наиболее краткий способ поиска имени пакета для данной программы. Как показано выше, yum и apt оба полагаются на путь, чтобы найти полезные результаты. Pacman делает некоторые разумные предположения относительно того, какой пакет вы, скорее всего, ищете:
Работа с AUR
Есть несколько популярных помощников менеджера пакетов AUR. Из них довольно популярны yaourt и pacaur. Однако в Arch Wiki оба проекта перечислены как остановленные или проблемные. По этой причине я обсужу aurman. Он работает почти так же, как pacman, за исключением того, что он ищет программы в AUR и включает некоторые полезные, хотя и потенциально опасные возможности. Установка пакета из AUR будет инициировать использование скриптов сборки стороннего разработчика. Вам будет предложено несколько раз сделать подтверждения для продолжения установки (я сократил вывод для краткости):
Заключение
Эта статья, конечно, показывает только основные возможности менеджеров пакетов. Есть также множество других менеджеров пакетов, которые я не мог охватить здесь. Некоторые дистрибутивы, такие как Ubuntu или Elementary OS, проделали большую работу, чтобы обеспечить графический интерфейс для управления пакетами.
DATAENGINER
Одним из основных отличий дистрибутивов Linux друг от друга является управление пакетами. В этой статье вы узнаете о пакетах и менеджерах пакетов в Linux. Вы узнаете, что такое пакеты, что такое менеджеры пакетов, как они работают и какие менеджеры пакетов доступны.
Что такое диспетчер пакетов в Linux?
Что такое пакет?
Пакет обычно относится к приложению, но это может быть приложение с графическим пользовательским интерфейсом, инструмент командной строки или программная библиотека (необходимая для других программ). Пакет — это, по сути, архивный файл, содержащий исполняемый двоичный файл, файл конфигурации и иногда информацию о зависимостях.
Чтобы избавиться от этой сложности, дистрибутивы Linux создали свой собственный формат упаковки, чтобы предоставить конечным пользователям готовые к использованию двоичные файлы (предварительно скомпилированное программное обеспечение) для установки программного обеспечения вместе с некоторыми метаданными (номер версии, описание) и зависимостями.
Это как испечь торт, а не купить торт.
Чтобы взаимодействовать с системами упаковки или использовать их, вам понадобится менеджер пакетов.
Как работает менеджер пакетов?
Поскольку в этой статье основное внимание уделяется Linux, я буду рассматривать ситуацию с точки зрения Linux. Однако большая часть объяснения здесь может быть применена и к диспетчеру пакетов в целом.
Я создал эту диаграмму (на основе SUSE Wiki), чтобы вы могли легко понять, как работает менеджер пакетов.
Почти все дистрибутивы Linux имеют репозитории программного обеспечения, которые в основном представляют собой набор программных пакетов. Да, может быть более одного репозитория. Репозитории содержат программные пакеты различного типа
В репозиториях также есть файлы метаданных, которые содержат информацию о пакетах, такую как имя пакета, номер версии, описание пакета и имя репозитория и т. д. Это то, что вы увидите, если используете команду apt show в Ubuntu / Debian.
Менеджер пакетов вашей системы сначала взаимодействует с метаданными. Диспетчер пакетов создает локальный кеш метаданных в вашей системе. Когда вы запускаете параметр обновления диспетчера пакетов (например, apt update), он обновляет этот локальный кеш метаданных, ссылаясь на метаданные из репозитория.
Когда вы запускаете команду установки вашего менеджера пакетов (например, apt install package_name), менеджер пакетов обращается к этому кешу. Если он находит информацию о пакете в кэше, он использует подключение к Интернету для подключения к соответствующему репозиторию и сначала загружает пакет перед установкой в вашу систему.
У пакета могут быть зависимости. Это означает, что может потребоваться установка других пакетов. Диспетчер пакетов часто заботится о зависимостях и автоматически устанавливает его вместе с пакетом, который вы устанавливаете.
Диспетчер пакетов, обрабатывающий зависимости в Linux
Точно так же, когда вы удаляете пакет с помощью диспетчера пакетов, он либо автоматически удаляет, либо сообщает вам, что в вашей системе есть неиспользуемые пакеты, которые можно очистить.
Помимо очевидных задач по установке и удалению, вы можете использовать диспетчер пакетов для настройки пакетов и управления ими в соответствии с вашими потребностями. Например, вы можете запретить обновление версии пакета из регулярных обновлений системы. Есть еще много вещей, на которые может быть способен ваш менеджер пакетов.
Различные типы менеджеров пакетов
Менеджеры пакетов различаются в зависимости от системы упаковки, но одна и та же система упаковки может иметь более одного менеджера пакетов.
Менеджер пакетов Synaptic
Вывод
Я не хочу вдаваться в подробности по этой теме, потому что могу продолжать и продолжать. Но это будет отклоняться от цели темы, которая состоит в том, чтобы дать вам базовое представление о диспетчере пакетов в Linux.
Я пока пропустил новые универсальные форматы упаковки, такие как Snap и Flatpak.
Я очень надеюсь, что вы немного лучше понимаете систему управления пакетами в Linux. Если вы все еще не уверены или у вас есть вопросы по этой теме, воспользуйтесь системой комментариев. Я постараюсь ответить на ваши вопросы и, если потребуется, дополню эту статью новыми моментами.
Управление пакетами Linux и как применять пакеты
Главное меню » Linux » Управление пакетами Linux и как применять пакеты
Пользователи Linux знают, что установка пакетов – это центральная часть использования приложений во вселенной Linux. Помимо загрузки приложений, пользователи Linux могут использовать установку пакетов для обновления патчей. Пользователи Linux обычно знают, что изменение ядра Linux может исправить ошибки в программном обеспечении, но с упакованными метаданными это не должно быть так сложно – просто установите новейшую зависимость в виде пакета, и обновления для вашего прикладного программного обеспечения могут быть полностью реализованы. с новым пакетом.
Что такое пакет?
Пакет – это контейнер для метаданных – содержимого, которое изменяет или расширяет функции вашей текущей операционной системы и может быть свернуто в более простой набор данных. По сути, пакеты – это способ установки приложений в Linux, независимо от того, предназначены ли эти приложения для исправления исправлений или расширения функций вашей системы.
Сам пакет является источником метаданных для вашей системы, который действует как удобный способ расширить функции вашей текущей операционной системы или изменить ошибки в исходном ядре. Чтобы установить пакет, вы должны изменить свое ядро, чтобы оно принимало новые метаданные. После того, как вы установили свой пакет, для MSP важно знать, как в полной мере использовать его функции.
Как правило, пользователи Linux имеют дело либо с распространением пакетов на основе Debian, либо с распространением на основе Red Hat. Хотя форматы этих двух программ установки пакетов различаются, они являются инструментами распространения Linux, которые упрощают управление пакетами.
В процессе управления пакетами Debian в качестве посредника используется двоичный файл Debian с инструментом dpkg. Возможно, наиболее распространенной программой управления пакетами для Linux является Ubuntu, которая использует хорошо известный интерфейс и имеет обширный репозиторий пакетов. Еще одна важная программа управления пакетами – это RPM Package Manager (RPM) от Red Hat.
Какие бывают типы пакетов?
Управление пакетами Debian с использованием двоичного файла Debian – один из способов управления пакетами для пользователей Linux. Концепция пакета Debian довольно проста: как только вы найдете пакет в выбранном вами репозитории, вы можете использовать простой набор команд dpkg для установки нового приложения.
Поскольку пакеты являются базами метаданных, пакеты на основе Debian содержат только три файла: двоичный файл Debian, файл данных и управляющий файл. Управляющий файл представляет собой ZIP-файл tar, что означает, что остальные данные пакета свернуты и запечатаны в управляющий файл. После установки этого пакета управляющий файл позволяет значительно расширить функции метаданных, которые в противном случае пришлось бы настраивать отдельно. Некоторые поставщики программного обеспечения, такие как Ubuntu, Debian, Mint и другие, предлагают двоичные пакеты Debian, которые вы можете применить к своей системе Linux, чтобы удовлетворить ваши конкретные потребности в упаковке.
Важно отметить, что инструменты управления пакетами на основе RPM и Debian синхронизируются для обновления своего кода для исправлений. Это означает, что после того, как ваш MSP будет работать с основным инструментом управления пакетами Linux, вам не придется устанавливать исправления или вручную обновлять свою программу для исправления ошибок.
Как применять пакеты в Linux?
Чтобы избежать длительного написания команд, компании-распространители пакетов предоставляют графические средства управления установкой пакетов. Эти визуальные инструменты являются основным источником различий между установкой пакетов в разных системах распространения. Хотя все пакеты предлагают одни и те же основные услуги, провайдеры услуг могут посчитать, что конкретный интерфейс лучше всего подходит для их нужд управления.
После того, как вы нашли свой пакет в соответствующем репозитории, вы можете использовать команды dpkg (для управления на основе Debian) или команды RPM для установки пакета в вашу систему. Каждый из этих поставщиков оснащен диспетчером архивов, который позволяет MSP визуализировать содержимое командного файла перед применением пакета в системе.
Если вам нужен больший контроль над процессом управления пакетами, некоторые поставщики пакетов позволяют поставщикам услуг вручную настраивать обновления кода пакета. Если вам нужно еще больше сказать о целостности вашего пакета, у MSP также есть возможность написать код пакета на основе Debian или RPM для создания исходного пакета с использованием стандартных форматов.
Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.
Пакеты
Пригодная для работы пользователя система состоит из множества (сотен и тысяч) программ и утилит. В Linux каждый компонент системы представлен в виде пакета. Все операции, связанные с изменением состава системы: установка, удаление, проверка, обновление компонентов, — производятся над пакетами. В целом, пакет — это средство сделать так, чтобы пользователь-администратор, изменяя или обновляя программное наполнение системы, работал не с файлами (имена которых ему подчас неизвестны), а с определёнными функциональностями самой системы: например, добавлял в неё не «500 файлов», а «WWW-сервер apache ».
Архив файлов
На первый взгляд, программа состоит из одного — исполняемого — файла: запускаем файл, получаем работающую программу. Однако во время работы даже самая простая программа использует другие файлы, содержащие различные ресурсы: библиотеки, конфигурационные файлы, файлы-дырки и даже запускает другие программы. Чтобы программа действительно заработала, необходимо помимо главного исполняемого файла обеспечить наличие в системе всех нужных файлов с ресурсами.
Понятно, что при установке или удалении программы нужно позаботиться и обо всех используемых ею файлах (которых может быть даже очень много). Это — первая задача пакетирования: все файлы, используемые программой, объединяются в один файл — архив. Это позволяет не копировать при установке программы все файлы по-отдельности, а потом не удалять их таким же способом, а работать со всеми данными программы как с одним целым — устанавливать и удалять один пакет.
файловый архив Дерево каталогов, представленное в виде единого файла, состоящего из содержимого всех файлов в этом дереве и информации об имени и атрибутах каждого файла.
tar появился намного раньше Linux и изначально служил для создания файловых архивов на магнитной ленте. Отсюда и его название — tape archiver, «архиватор для (магнитных) лент». В настоящее время tar присутствует в любой UNIX-подобной системе и позволяет работать с файловыми архивами на любых носителях.
С каждым указанным каталогом tar работает рекурсивно, т. е. запаковывает все содержащиеся в нём файлы и подкаталоги.
При распаковке архива tar файлы извлекаются вместе с путём, недостающие подкаталоги создаются по мере необходимости. Все пути tar считает относительными от своего рабочего каталога. Если теперь Мефодий распакует свой архив (командой « tar xf имя_архива »), то в рабочем каталоге будет создан подкаталог « bin/ » и в него будут записаны все файлы из архива.
Ключ « v » велит tar быть «разговорчивым» (verbose), т. е. выводить больше диагностичских сообщений, блаодаря этому tar при распаковке выводит имена (с путём) всех записываемых файлов. Если в рабочем каталоге уже есть файл, который tar собирается создать при распаковке, то этот файл будет попросту заменён файлом из архива. Так, когда Мефодий распаковал свой архив, подкаталог « bin/ » со всем его содержимым заменился на подкаталог из архива. В данной ситуации это не страшно, поскольку в архиве файлы такие же, но вот если бы Мефодий перед распаковкой изменил какие-то из своих файлов в « bin/ », он лишился бы всех изменений.
Формат пакета
Регистрация в системе
Итак, пакет с компонентом системы — это в первую очередь файловый архив, в котором хранятся все необходимые файлы вместе с путями к ним (т. е. каталогами). Когда компонентов много, нужно обеспечить, чтобы в разных пакетах не оказалось файлов с одинаковым именем и путём, чтобы файл, принадлежащий одному пакету, не мог быть заменён файлом другого пакета при установке. Отслеживать такого рода конфликты пакетов — вторая задача пакетирования.
Чтобы предупреждать конфликты, в системе должна храниться информация обо всех уже установленных пакетах и принадлежащих им файлах. Когда точно известно, какие файлы принадлежат пакету, можно полностью удалить пакет, не оставив и не удалив при этом ничего лишнего. Такой подход препятствует образованию в системе «мусора» — бесполезных файлов, оставшихся от удалённых программ — и делает операцию установки/удаления пакета полностью обратимой.
Мефодий получил довольно длинный список имён файлов, среди которых встретил многие из уже знакомых ему утилит и кое-какие незнакомые. Причём запрашивая список файлов, Мефодий использовал только имя пакета, без версии — rpm позволяет обращаться так любому из установленных пакетов2.
Можно выполнить и обратную процедуру — выяснить про любой файл, какому пакету он принадлежит:
Мефодий получил список изменившихся с момента установки пакета файлов. Видимо, всё это — конфигурационные файлы, отредактированные администратором системы. Мефодий догадался, что комбинация цифр, букв и точек — это список атрибутов, по которым rpm сравнивал установленные файлы с данными пакета, однако чтобы разобраться, что именно означает каждая буква, ему придётся внимательнее читать руководство.
Система Linux раскладывается на компоненты без остатка: каждый файл в Linux принадлежит какому-нибудь (и только одному!) пакету.
Естественно, кроме тех файлов, которые созданы пользователями.
Изменение настроек системы
Для полноценной регистрации пакета в системе обычно недостаточно, чтобы система хранила список файлов, принадлежащих пакету. При установке, удалении или обновлении пакета часто требуется выполнить ряд операций, чтобы обновить сведения о пакете, адаптировать настройки — как самого пакета к уже имеющимися в системе, так и наоборот. К тому же, некоторые изменения в системе, например, добавление и удаление псевдопользователя, не сводятся к добавлению и удалению файлов, и вдобавок зависят от текущего состояния системы. Получается, что регистрация в системе — дело не только системы, но и самого пакета. Поэтому в каждом пакете должны храниться сведения о том, какие действия следует выполнить в момент различных операций с ним — в этом состоит третья задача пакетирования.
Списки необходимых действий представлены в пакете в виде сценариев. Эти сценарии привязаны к процедурам установки и удаления пакета, причём могут быть вызваны по необходимости как до, так и после соответствующей процедуры. В результате процедуры установки и удаления пакета выглядят так:
Мефодий выяснил, что сценарии в пакете coreutils запускаются перед началом установки (preinstall), после установки (postinstall) и перед удалением (preuninstall), они выполняются стандартным командным интерпретатором ( /bin/sh ). Все эти сценарии нужны для того, чтобы зарегистрировать в системе info установленную пакетом документацию или удалить эту документацию из системы (командами /usr/sbin/install_info и /usr/sbin/uninstall_info соответственно). Поскольку info строит общее оглавление всей имеющейся в системе документации, простого копирования файлов было бы недостаточно.
В результате подобных операций по интеграции пакета в систему могут быть изменены или удалены файлы, не принадлежащие данному пакету, созданы новые файлы. Если программа, содержащаяся в пакете, пользуется услугами какой-нибудь уже установленной службы (например, syslogd ), может понадобиться регистрация этой программы в конфигурационных файлах службы. Конечно, изменение «чужих» файлов в процессе установки пакета нежелательно: впоследствии, удаляя пакет, потребуется вернуть файл в исходное состояние, что не всегда возможно (например, после вдумчивого редактирования администратором). Избежать редактирования конфигурационных файлов позволяет схема «. d», описанная в лекции Этапы загрузки системы.
Цена удобства
Удобство, которое получает пользователь при работе с пакетами достигается не само собой, а человеческим трудом: пакеты должен создавать человек, его работа называется «сопровождающий» («package maintainer» или «packager»). В обязанности сопровождающего пакет входит подготовка файлового архива, необходимых для установки и удаления сценариев и прочей информации о пакете и его содержимом, и объединение их в одном файле-пакете.
Нужно принимать во внимание, что любой пакет, содержащий программное обеспечение для Linux, не является универсальным. Если у вас есть такой пакет, это ещё не означает, что его можно установить в вашей системе. Дело в том, что разные дистрибутивы Linux различаются именно тем, каким образом программное обеспечение организовано в систему (о дистрибутивах речь пойдёт в лекции Политика свободного лицензирования. История Linux: от ядра к дистрибутивам). Дистрибутивы могут различаться размещением файлов и процедурами, предусмотренными для интеграции в систему программного обеспечения, не говоря уже о том, что в разных дистрибутивах используется разный формат пакетов. Это значит, что пакет, подготовленный с ориентацией на один дистрибутив, может оказаться несовместимым с другим. Чтобы в вашем дистрибутиве появилась некоторая программа, кто-то должен подготовить и сделать доступным соответствующий пакет.
пакет Ресурсы, необходимые для установки и интеграции в систему некоторого компонента (архив файлов, до- и послеустановочные сценарии, информация о пакете и его сопровождающем), объединённые в одном файле.
Несмотря на частные различия, дистрибутивы Linux представляют собой варианты одной и той же системы, поэтому в конечном итоге любую программу, работающую в одном дистрибутиве, можно «приспособить» к любому другому. Только для этого нужно располагать исходными текстами соответствующей программы. До сих пор речь шла только о так называемых двоичных пакетах, в которых программы содержатся в виде уже скомпилированных двоичных (исполняемых) файлов, в таком виде программа может зависеть от некоторых свойств системы и работать не везде. Чтобы получить работающую программу в системе, нужно установить именно двоичный пакет. Однако пакет может содержать и исходные тексты программ, такие пакеты называются исходными. Доступность исходных кодов — обязательное условие распространения большей части программного обеспечения для Linux, см. лекцию Политика свободного лицензирования. История Linux: от ядра к дистрибутивам. Если получилось так, что никто не подготовил пакет с нужной вам программой для вашего дистрибутива, у вас есть возможность установить исходный пакет и скомпилировать программу самостоятельно.
Слухи о том, что для сборки программы из исходных текстов не обязательно даже знать, что такое «компилятор», далеки от действительности.
При успешной компиляции из исходного пакета получается соответствующий двоичный, который уже можно установить в системе.