Управление программным обеспечением

Исторически сложилось так, что разные компоненты современных UNIX-подобных ОС, разрабатывались и продолжают разрабатываться независимо и в разных местах. Наиболее ярко это проявляется в ОС на основе ядра Linux, где независимо разрабатываются все компоненты системы, начиная с ядра и системообразующих библиотек и заканчивая прикладными программами. Такой подход к созданию ОС стал возможен благодаря стандартизации ОС UNIX на всех уровнях (о чём говорилось в разделе «Развитие операционных систем в глобальных сетях»). Именно благодаря компонентной архитектуре UNIX стало возможным появление в 1990-х годах полнофункциональных серверных и настольных систем, состоящих исключительно из свободных программ, таких как Linux и FreeBSD; ни одному свободному проекту было не под силу создать полноценную систему, но оказалось возможным объединить усилия многих проектов, создав интегрированную систему на основе стандартов.

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

Таким образом, в задачи управления программным обеспечением в компонентой системе входит в первую очередь поддержание целостности системы, т. е. синхронизация версий разного ПО (которое постоянно и независимо друг от друга развивается) в рамках системы. Кроме того, необходимо по возможности упростить и унифицировать задачи установки, удаления и обновления ПО для администратора системы, все компоненты которой происходят из разных источников. Данная лекция посвящена различным методам решения этих задач, сложившимся в мире UNIX-систем.

Управление программным обеспечением: роли и задачи

Основные роли в создании и использовании ПО

Презентация 8-01: основные роли при работе с ПО

Создание и использование любого программного обеспечения предполагает существование следующих ролей:

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

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

В сложившейся современной модели распространения свободного ПО выделилась ещё одна группа ролей — разработчики дистрибутивов, которые берут на себя функции интеграторов, объединяющих различные независимые компоненты в целостные и готовые к использованию «решения». Наибольшее значение роль разработчиков дистрибутивов получила в операционной системе Linux.

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

Рисунок 3.15. Основные роли в процессе создания и использования ПО

Основные роли в процессе создания и использования ПО


Задачи системы управления программным обеспечением

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

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

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

Формы распространения программного обеспечения

В двоичной форме или в исходных текстах?

Презентация 8-02: распространение ПО в двоичной форме и в исходных текстах

Самым простым способом распространения программы является простой файловый архив, который содержит исполняемый файл, набор библиотек и других файлов, необходимых для запуска программы. Но распространение программ в двоичном виде связано с рядом проблем: исполняемые файлы различаются для разных архитектур и операционных систем (UNIX-подобные операционные системы имеют общие стандартные интерфейсы, а не реализации). В результате двоичная программа «для UNIX» обычно оказывается реально применимой на очень узком круге платформ. Применимость такой программы также стремительно падает с течением времени: быстро устаревают аппаратные архитектуры, меняются реализации системообразующих компонентов, меняются даже стандарты.

Рисунок 3.16. Распространение ПО в двоичной форме

Распространение ПО в двоичной форме


В настоящий момент распространение программ только в двочном виде характерно для проприетарных версий UNIX: AIX, HP-UX, MacOS X, Solaris и др. Эти версии UNIX чаще всего поставляются для небольшого регламентированного списка аппаратных платформ.

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

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

Сборочные процедуры как средство управления ПО

В тот период, когда UNIX-сообщество было, в первую очередь, сообществом разработчиков, предполагалось, что средства разработки установлены в любой UNIX-системе, где может быть востребована программа, распространяемая в виде исходных текстов. Поэтому вполне естественно сложилось, что средства, используемые для компиляции и сборки программ (например, утилита make), были приспособлены и для решения задач из области уже системного администрирования: установки и удаления полученных программ.

Рисунок 3.17. Распространение ПО в форме исходных текстов

Распространение ПО в форме исходных текстов


Make-файл определённого вида к настоящему времени является стандартом де-факто для большинства открытых проектов. С его помощью можно получить готовую к использованию программу из исходных текстов на компилируемом языке (как правило это C или C++). Обычно в make-файле определяются специальные цели для задач системного администрирования: install и uninstall, которые выполняют стандартные действия — соответственно, установку и удаление скомпилированной программы из системы. При этом всё, что требуется от администратора для компиляции из исходных текстов и установки программы — это выполнить следующую последовательность команд:

Пример 3.5. Сборка и установка программы с помощью make

desktop src # tar -xzf a-program-1.00.tar.gz
desktop src # cd a-program-1.00
desktop a-program-1.00 # make
... происходит компиляция и сборка программы ...
desktop a-program-1.00 # make install
... программа устанавливается в систему ...


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

С увеличением числа программ в системе (любая современная система — это тысячи компонентов) такой подход к управлению ПО стал малоприменимым как исключительно затратный для системного администратора.

Дополнительный источник осложнений представляют собой зависимости программ. Так, крупные современные проекты могут использовать десятки других программ и библиотек (например, веб-сервер apache зависит от десятка других проектов, начиная от базовой системной библиотеки libc и заканчивая библиотекой expat для синтаксического анализа XML). Так как большинство проектов развивается независимо друг от друга, и новые версии выпускаются довольно часто, отслеживание зависимостей и корректное обновление программ могут превратиться в сущий ад для администратора.

Дальнейшую автоматизацию работы администратора в отношении отслеживания зависимостей и различий в реализации разных UNIX-систем в рамках той же модели — посредством сборочных процедур — предоставляют программы пакета autotools: automake и autoconf. Эти средства по существу реализуют адаптивные сборочные процедуры, которые способны настраиваться в зависимости от особенностей сборочной среды. Они позволяют на основе анализа присутствующих в системе программ и библиотек, особенностей операционной системы и аппаратной архитектуры автоматически получить make-файл, по которому будет произведена компиляция и установка программы.

Дистрибутивы

Презентация 8-03: виды дистрибутивов

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

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

Пакет — это специальный файловый архив, который содержит программу/ набор программ или указание на способ получения программы (например, адрес в Интернете) вместе с формализованной информацией, необходимой для интеграции данной программы в систему. Разница между пакетом и программой аналогична разнице между службой и демоном (см. «Системные службы») — администратор работает с пакетом в терминах его функциональности.

Введение понятия пакет, помимо прочего, позволяет формализовать понятие зависимости, указывая в метаинформации пакета имена и версии других пакетов, от которых зависит данный. Таким образом, при установке пакета можно автоматически отслеживать наличие в системе всех необходимых для него компонентов (других пакетов нужных версий), о чём ещё будет сказано далее (см. раздел «Зависимости пакетов»).

Дистрибутивы, основанные на сборке программ из исходных текстов

Изначально идея систематизации сборки программ, составляющих UNIX-систему, из исходных текстов развилась в BSD-системах (см. также «Системы, наследующие BSD»). В них (изначально во FreeBSD) было введено понятие порта — пакета специального вида, который сам не содержит исходных текстов, а только адрес их местонахождения (как правило, сайт разработчика), но содержит главную «точку приложения» знаний: дополнительные изменения, внесённые разработчиками дистрибутива, и формализованные инструкции по сборке.

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

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

Среди широко используемых дистрибутивов GNU/Linux на сборке из исходных текстов основан Gentoo. Собственная, усовершенствованная версия портов, названная портежи (portages), позволяет сконфигурировать систему под конкретную задачу и даже специфическую архитектуру.

Рисунок 3.18. Распространение ПО в форме портов/портежей

Распространение ПО в форме портов/портежей


Однако при таком распределении задач (компиляция на стороне администратора системы) сохраняется длительность процесса установки и зависимость от используемых средств разработки — даже на сервере приходится устанавливать компилятор gcc.

Дистрибутивы, основанные на двоичных пакетах

Другим путём пошли разработчики многих дистрибутивов, основанных на распространении двоичных пакетов. Первые примеры использования двоичных пакетов в дистрибутивах Linux относятся к ранним версиям дистрибутивов Debian, Red Hat и Slackware. Основное отличие подхода заключается в том, что системному администратору компоненты системы предлагаются не в виде пакетов с исходными текстами, а в виде пакетов, содержащих двоичные, скомпилированные версии программ. Таким образом с администратора системы снимается необходимость иметь средства разработки (сборочную среду) и тратить время на сборку программ. Более того, поскольку пакет содержит также и процедуры установки/удаления программы, основные задачи управления ПО становятся вполне доступными и пользователю, не имеющему специальной подготовки.

Описанные выше (см. раздел «Формы распространения программного обеспечения») проблемы, связанные с распространением двоичных программ, в логике таких дистрибутивов решены так: разработчики предоставляют дистрибутив, представляющий собой полноценную систему для решения определённого класса задач и поддерживающий определённый круг оборудования. Пользователю остаётся только выбрать подходящий дистрибутив и устанавливать и обновлять необходимые ему компоненты — пакеты. Работоспособность пакетов на данной аппаратной платформе, их интеграцию в системе, отслеживание зависимостей обеспечивают разработчики дистрибутива. Точнее, в рамках дистрибутива у каждого пакета традиционно имеется сопровождающий (package maintainer) или группа сопровождающих. Это ограничивает пользователя теми программами, что представлены в дистрибутиве. Установка любого ПО из других источников влечёт все описанные выше проблемы и требования для системного администратора или пользователя.

Рисунок 3.19. Распространение ПО в форме двоичных пакетов

Распространение ПО в форме двоичных пакетов


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

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

С развитием Internet пакетные системы стали выносить на публику репозитории пакетов — хранилища пакетов системы, содержащие «текущее состояние» системы, множетство всех пакетов и зависимостей между ними. Репозитории удобны тем, что они находятся в «живом» состоянии — пакеты постоянно обновляются разработчиками дистрибутива и могут быть загружены и установлены пользователем. Как правило, для автоматизации и удобства работы с репозиторием (а именно, установки пакетов с удовлетворением всех зависимостей) используется специальная программа (например, APT). Имея постоянный доступ в Internet, можно развернуть всю систему из небольшого начального набора пакетов, включающего базовую систему и программу по работе с репозиторием.

Надо отметить, что акцент на двоичные пакеты в таких системах не мешает им также распространять пакеты с исходными текстами программ. Как структура таких пакетов, так и принципы работы с ними в основных чертах совпадают с портами и портежами в дистрибутивах, основанных на сборке из исходных текстов.

Презентация 8-04: из чего состоит пакет

Существует несколько широко распространённых форматов пакетов, обычно связанных с различными дистрибутивами. Но в каждом из форматов будут присутствовать следующие логические составляющие (см. Рисунок 3.20, «Основные составляющие пакета»).

Рисунок 3.20. Основные составляющие пакета

Основные составляющие пакета


название

Имя программы (например, «apache») или функции, закреплённой за пакетом (например, «basesystem» — файлы и программы, составляющие основу системы).

версия

Версия программы, присвоенная разработчиками, обычно дополняется версией пакета в рамках дистрибутива (например, «pciutils-2.1.11-alt10»).

зависимости

Список пакетов с версиями, необходимых для установки и работы данного пакета. Как правило, пакеты в системе образуют решетку зависимостей.

автор(ы)

Имя и контактная информация автора или коллектива авторов программы, адрес домашней страницы проекта.

описание

Информация о пакете, соответствующей программе или функции.

содержимое

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

Самые распространённые на данный момент дистрибутивы Linux — Debian и Red Hat — являются типичными примерами систем с двоичными пакетами (rpm для Red Hat и deb для Debian). Эти два формата пакетов используются также и в других дистрибутивах — Mandriva, ALT Linux, Ubuntu и т. д.

Презентация 8-05: зависимость и конфликт

Зависимости пакетов

Пакеты в системе выстраиваются в сеть зависимостей и блокировок. Например, веб-сервер apache может зависеть от множества пакетов, т.е. администратору придётся установить все из них перед установкой самого пакета apache. На рисунке Рисунок 3.21, «Пример зависимостей пакетов в системе» показан пример реальных зависимостей пакетов в одном из дистрибутивов GNU/Linux. Аналогичная ситуация возникает и при удалении пакета: удаление одной из зависимостей, вообще говоря, некорректно и может привести к отказу работы программ из основного пакета.

Рисунок 3.21. Пример зависимостей пакетов в системе

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

Зависимость между пакетами системы может основываться на:

  • функциональной зависимости, например, программы от библиотеки (например, библиотеки libreadline, предоставляющей функцию гибкого ввода текста в командной строке);
  • зависимости от набора данных или конфигураций (так, пакет terminfo предоставляет набор конфигураций терминалов);
  • зависимости при установке — при отсутствии данного пакета в системе не удастся развернуть и проинициализировать зависящий от него пакет;
  • виртуальные зависимости — используются для объединения пакетов в группы, удобные для установки и обновления (например, пакет glibc зависит от множества пакетов вида glibc-*, включающих отдельные компоненты базовой системной библиотеки).

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

Рисунок 3.22. Пример конфликта пакетов в системе

Пример конфликта пакетов в системе

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

Для работы с каждым из форматов пакетов предназначены специальные программы — менеджеры пакетов: в случае rpm-пакетов это rpm, а в случае deb-пакетов — dpkg. Как правило, основные административные операции можно выполнять с помощью этих программ, однако в каждом дистрибутиве обычно предлагаются собственные более высокоуровневые системы для управления пакетами и работы с репозиториями пакетов.

В рамках данного курса будет рассматриваться управление пакетами на основе rpm (как низкоуровневого средства работы с пакетам) и APT (как высокоуровневого интерфейса к нему), которое можно применить к ряду дистрибутивов Linux. Нужно отметить, что реализация управления пакетами с помощью rpm может отличаться в различных дистрибутивах Linux, здесь же рассматривается дистрибутив ALT Linux.

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

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

Исходя из названных выше задач администратора в системе с бинарными пакетами легко определяется круг задач rpm: управление файловым архивом, выявление зависимостей и конфликтов, непосредственная установка и удаление файлов.

RPM-пакеты

Презентация 8-06: название RPM-пакета

Обычно файлы RPM-пакетов имеют специальным образом построенные имена: имя_пакета-версия_программы-версия_пакета.архитектура.rpm

имя пакета

Может соответствовать программе или библиотеке, заключённой в этом пакете, либо же задавать его назначение (например, setup или initscripts).

версия программы

Версия программы или библиотеки, которая составляет основу пакета (например, в случае пакета automake-1.9.2-3 это 1.9.2).

версия пакета

Для каждой версии программы может существовать несколько версий пакетов. Это связано с тем, что создатели дистрибутива GNU/Linux могут изменять программу, внося свои патчи, или же изменять сам пакет — установочные скрипты, описание и т. п.. Например, пакет xmms-1.2.10-9 имеет уже девятую версию. В некоторых дистрибутивах GNU/Linux к версии пакета прибавляют специальную приставку, например: pciutils-2.1.11-alt10 в ALT Linux.

архитектура

Программы могут быть скомпилированны под разные аппаратные архитектуры, например i386 для Intel x86-совместимых процессоров или ppc для POWER от IBM. Пакеты, которые не содержат скомпилированных программ или библиотек (например, сценарии или конфигурационные файлы) обычно обозначаются как noarch.

Практические вопросы работы с программой rpm рассматриваются в разделе: «Вопросы».

Работа с репозиториями пакетов: APT

Презентация 8-07: работа с репозиторием

Среди дистрибутивов GNU/Linux стало распространённым явлением размещение пакетов в Интернет, в так называемом репозитории пакетов. Администратор может загрузить оттуда самую последнюю версию пакета и установить его в системе. Для облегчения работы с репозиторием существуют специальные программы, такие как APT в Debian или yum в Red Hat.

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

Для автоматизации этого процесса и применяется Усовершенствованная система управления программными пакетами APT (от англ. Advanced Packaging Tool). Такая автоматизация достигается созданием одного или нескольких внешних репозиториев, в которых хранятся пакеты программ и относительно которых производится сверка пакетов, установленных в системе. Репозитории могут содержать как официальную версию дистрибутива, обновляемую его разработчиками по мере выхода новых версий программ, так и локальные наработки (например, пакеты, разработанные внутри компании).

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

Первоначально APT был разработан для управления установкой и удалением программ в дистрибутиве Debian GNU/Linux. При разработке ставилась задача заменить используемую в Debian систему выбора программных пакетов dselect на новую, обладающую большими возможностями и простым пользовательским интерфейсом, а также позволяющую производить установку, обновление и повседневные «хозяйственные» работы с установленными на машине программами без необходимости изучения тонкостей используемого в дистрибутиве менеджера программных пакетов.

Эти привлекательные возможности долгое время были доступны только пользователям Debian, поскольку в APT поддерживался только один менеджер пакетов, а именно применяемый в Debian менеджер пакетов dpkg. APT, однако, изначально проектировался как не зависящий от конкретного метода работы с установленными в системе пакетами, и эта особенность позволила разработчикам из бразильской компании Conectiva реализовать в нём поддержку менеджера пакетов RPM. Таким образом, пользователи основанных на RPM дистрибутивов получили возможность использовать этот мощный инструмент.

Система APT состоит из нескольких утилит. Чаще всего используется утилита управления пакетами apt-get: она автоматически определяет зависимости между пакетами и строго следит за их соблюдением при выполнении любой из следующих операций: установка, удаление или обновление пакетов.

Источники программ (репозитории)

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

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

APT позволяет взаимодействовать с репозиторием с помощью различных протоколов доступа. Наиболее популярные — HTTP и FTP, однако существуют и некоторые дополнительные методы.

Для того, чтобы APT мог использовать тот или иной репозиторий, информацию о нем необходимо поместить в файл /etc/apt/sources.list[4]. Описания репозиториев заносятся в этот файл в следующем виде:

rpm [подпись] метод:путь база название
rpm-src [подпись] метод:путь база название
rpm или rpm-src

Тип репозитория (скомпилированные программы или исходные тексты);

подпись

Необязательная строка-указатель на электронную подпись разработчиков. Наличие этого поля подразумевает, что каждый пакет из данного репозитория должен быть подписан соответствующей электронной подписью. Подписи описываются в файле /etc/apt/vendor.list;

метод

Способ доступа к репозиторию: ftp, http, file, rsh, ssh, cdrom;

путь

Путь к репозиторию в терминах выбранного метода;

база

Относительный путь к базе данных репозитория;

название

Название репозитория;

После того, как отредактирован список репозиториев в sources.list, необходимо обновить локальную базу данных APT о доступных пакетах. Это делается командой apt-get update.

Если в sources.list присутствует репозиторий, содержимое которого может изменяться (как происходит с любым постоянно разрабатываемым репозиторием), то прежде, чем работать с APT, необходимо синхронизировать локальную базу данных с удалённым сервером командой apt-get update. Локальная база данных создаётся заново каждый раз, когда в репозитории происходит изменение: добавление, удаление или переименование пакета.

При выборе пакетов для установки APT руководствуется всеми доступными репозиториями, вне зависимости от способа доступа к ним. Так, если в репозитории, доступном по сети Интернет, обнаружена более новая версия программы, чем на компакт-диске, то APT начнёт загружать данный пакет из Интернет. Поэтому если подключение к Интернет отсутствует, или ограничено низкой пропускной способностью канала, или выской стоимостью, то следует закомментировать те строчки в /etc/apt/sources.list, в которых говорится о ресурсах, доступных по Интернет.

Практические вопросы работы с командами apt-get и apt-cache рассматриваются в разделе: «Вопросы».

Резюме

Презентация 8-08: резюме

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

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

Современные UNIX-подобные системы предлагают средства управления программами как на основе компиляции программ, так и на основе двоичных пакетов.

Наиболее распространённым форматом (и менеджером) пакетов является rpm, впервые использованный в дистрибутиве Red Hat.

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

Ключевые термины: зависимость, целостность системы, makefile, пакет, порт, сопровождающий, репозиторий, конфликт

Дополнительные материалы

  1. Курячий Г.В., Маслинский К.А. Операционная система Linux. — М.: Интуит.Ру, 2005. — 392 с.: ил.

Вопросы

Презентация

Рисунок 3.23. Презентация 8-01: основные роли при работе с ПО

Презентация 8-01: основные роли при работе с ПО


Рисунок 3.24. Презентация 8-02: распространение ПО в двоичной форме и в исходных текстах

Презентация 8-02: распространение ПО в двоичной форме и в исходных текстах


Рисунок 3.25. Презентация 8-03: виды дистрибутивов

Презентация 8-03: виды дистрибутивов


Рисунок 3.26. Презентация 8-04: из чего состоит пакет

Презентация 8-04: из чего состоит пакет


Рисунок 3.27. Презентация 8-05: зависимость и конфликт

Презентация 8-05: зависимость и конфликт


Рисунок 3.28. Презентация 8-06: название RPM-пакета

Презентация 8-06: название RPM-пакета


Рисунок 3.29. Презентация 8-07: работа с репозиторием

Презентация 8-07: работа с репозиторием


Рисунок 3.30. Презентация 8-08: резюме

Презентация 8-08: резюме




[4] Если быть точным, этот файл может называться и иначе, другое имя файла со списком источников программ можно указать в конфигурационном файле /etc/apt/apt.conf. Подробнее о формате файла apt.conf можно узнать из руководства apt.conf(5).