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

Что такое зависимости пакетов

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

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

Практически любой софт устанавливаемый в современную linux систему можно найти в Интернете. Он может быть предоставлен разработчиками конкретного дистрибутива через официальные репозитарии (хранилища программного обеспечения, которые могут содержать тысячи пакетов, каждый из которых был скомпилирован, протестирован и поддерживается для распространения и использования в данном дистрибутиве linux ) или доступен в виде исходного кода, который можно загрузить и установить вручную. Поскольку разные семейства дистрибутивов linux используют разные системы упаковки (Debian - пакеты в формате deb , CentOS - rpm формат, openSUSE - тоже rpm но созданный специально для openSUSE ), пакет, предназначенный для одного дистрибутива, не будет совместим с другим дистрибутивом. Большинство дистрибутивов linux входят в одно из трех основных семейств linux , включенных в сертификацию LFCS .

Высоко- и низкоуровневые инструменты управления пакетами.

При решении различных задач по управлению пакетами программного обеспечения, необходимо знать, что существуют два типа утилит: низкоуровневые инструменты (производящие фактическую установку, обновление и удаление файлов пакетов), и высокоуровневые инструменты (отвечают за выполнение задач по разрешению зависимостей и поиска метаданных - так называемые "данные о данных"). Низкоуровневые системы управления пакетами:

• Debian , Ubuntu и подобные - менеджер пакетов dpkg
• CentOS - менеджер пакетов rpm
• OpenSUSE - менеджер пакетов rpm (opensuse )

Высокоуровневые системы управления пакетов:

• Debian , Ubuntu и подобные - apt-get/aptitude
• CentOS - менеджер пакетов yum
• OpenSUSE - менеджер пакетов zipper

Dpkg - низкоуровневый пакетный менеджер в Debian linux Dpkg умеет устанавливать, удалять, предоставлять информацию и создавать deb пакеты, однако он не может автоматически загружать и устанавливать необходимые зависимости для конкретного пакета. Apt-get - высокоуровневый пакетный менеджер в Debian linux и производных дистрибутивах. Apt-get представляет из себя простой способ получения и установки необходимых пакетов из различных источников, с разрешением зависимостей, через командную строку. В отличии от dpkg , apt-get не работает напрямую с .deb файлами пакетов, только пакетом по его имени. Aptitude , это еще один высокоуровневый инструмент управления пакетами в debian -подобных операционных системах и может быть использован для управления пакетами (установка, обновление и удаление пакетов с автоматическим разрешениме зависимостей), быстрым и простым способом. Он обеспечивает те же функциональные возможности что и apt-get , плюс некоторые расширенные, такие как доступ к нескольким версиям пакета. Rpm - система управления пакетами, используемая Linux Standard Base (LSB) - совместимыми дистрибутивами для низкоуровневой обработки пакетов. Как и dpkg , он может запрашивать, устанавливать, проверять, обновлять и удалять пакеты, чаще используется в дистрибутивах на базе Fedora , таких как RHEL и CentOS . Yum - высокоуровневый инструмент для работы с пакетами (установка, удаление, обновление), с управлением зависимостями в системах на основе RPM пакетов. Yum как apt-get и aptitude , работает с репозитариями

Распространенные задачи низкоуровневых инструментов.

1. Установка пакета из скомпилированного *.deb или *.rpm файла.

Минус подобной установки, это невозможность разрешения зависимостей пакета. Вероятней всего вы будете использовать данный способ установки, если в репозитариях соответствующее ПО отсутствует и не может быть установлено с помощью инструментов высокого уровня. В данном случае, пакет не сможет скачать и установить зависимости, если они ему потребуются, и установка будет прервана ошибкой. # dpkg -i file.deb # rpm -i file.rpm Не пытайтесь устанавливать в CentOS , rpm пакет, скомпилированный для OpenSUSE , и наоборот.

2. Обновление пакета из скомпилированного файла.

Обновить пакет ПО не доступный из репозитариев, возможно только вручную. # dpkg -i file.deb # rpm -U file.rpm

3. Список установленных пакетов

Если в ваше распоряжение попала уже работающая система, будет не лишним узнать, что на ней установлено: # dpkg -l # rpm -qa Если вам нужно узнать, установлен-ли какой-то конкретный пакет, можно воспользоваться командой grep . перенаправив на нее вывод менеджера пакетов: # dpkg -l | grep apache2-mpm-itk ii apache2-mpm-itk 2.2.22-13+deb7u6 amd64 multiuser MPM for Apache 2.2 # rpm -qa | grep httpd-2.4.6 httpd-2.4.6-45.el7.centos.4.x86_64 Еще один способ получить аналогичный результат: # dpkg --status package_name # rpm -q package_name 4. Какому пакету принадлежит файл. # dpkg --search my.cnf mysql-common: /etc/mysql/my.cnf # rpm -qf /etc/my.cnf mariadb-libs-5.5.52-1.el7.x86_64

Распространенные задачи высокоуровневых инструментов

1. Поиск пакетов

# aptitude update && aptitude search package_name # zypper refresh && zypper search package_name # yum search package_name если yum получает ключ search all , поиск производится не только по имени пакета но и по описанию # yum search all package_name Каким пакетом установлен файл # yum whatprovides "*/server.cnf" 1:mariadb-server-5.5.52-1.el7.x86_64: The MariaDB server and related files Repo: base Matched from: Filename: /etc/my.cnf.d/server.cnf

2. Установка пакета из репозитария

При установке пакета вам может быть предложено подтвердить установку после того, как менеджер пакетов разрешит все зависимости. # aptitude update && aptitude install package_name # zypper refresh && zypper install package_name # yum update && yum install package_name

3. Удаление пакетов

Если aptitude указан ключ remove , пакет будет удален, за исключением конфигурационных файлов. Что-бы удалить все следы установки пакета, нужно использовать ключ purge . # aptitude remove/purge package_name # yum erase package_name В OpenSUSE обратите внимание на знак "минус" перед именем пакета. # zypper remove -package_name Практически любой менеджер пакетов потребует подтвердить удаление пакета.

4. Просмотр инфоормации о пакете

Вывод информации о пакете mariadb-server # aptitude show mariadb-server # yum info mariadb-server # zypper info mariadb-server Удачи.

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

[Соколов Роман (romanso AT rt.mipt.ru)]

Установка программных пакетов в Linux для начинающих

Два способа установки ПО.

Необходимость в установке новых программных пакетов под LINUX возникает в двух основных случаях:

• когда появляется новая версия одного из уже установленных у Вас пакетов;
• когда возникает необходимость использования какой-то пакета, еще не установленного в системе.

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

Существует две основных формы распространения ПО для LINUX: в исходных текстах и в виде исполняемых модулей. И в том и в другом случае пакет ПО может поставляться либо в виде tar-gz архива, либо в виде rpm-пакета.

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

Программа rpm.

Название этой программы (или команды) является аббревиатурой от Redhat Package Manager. Такая расшифровка дается в большинстве книг и руководств по Линукс и кажется мне более правильной и логичной, хотя в главе 6 "The Official Red Hat Linux Reference Guide" говорится: "The RPM Package Manager (RPM), is an open packaging system available for any-one to use, and works on Red Hat Linux as well as other Linux and UNIX systems".

Программа rpm в некотором смысле аналогична программам типа setup wizard для MS Windows. Преимуществом использования этой программы по сравнению с установкой tar-gz архивов является то, что она автоматически проделает все необходимые действия по установке ПО: создаст необходимые каталоги, распределит по ним файлы, создаст ссылки. Кроме того, она может быть использована не только для установки нового пакета, но и для обновления версий ПО, получения перечней установленного ПО и проверки установки, а также для деинсталляции отдельных пакетов (например, если после периода пробной работы с программой Вы решили отказаться от ее дальнейшего использования). С помощью той же программы rpm можно самому создать пакет формата rpm, однако для начинающих лучше, наверное, этим не заниматься, а воспользоваться готовыми rpm-пакетами.

rpm-пакеты - это специальным образом подготовленные архивы, предназначенные для обработки программой rpm. Название rpm-пакетов оканчивается на суффикс.rpm, например, xzip-180-1.i386.rpm или xzip-180-1.src.rpm. Как видите, перед суффиксом.rpm стоит еще один суффикс. Если это.i386 или.i586, то в пакете находятся исполняемые файлы, а если этот суффикс.src, - то в пакете исходные тексты, которые после установки еще надо скомпилировать. Обычно и на установочных компакт-дисках и в Интернет-каталогах rpm-пакеты с исполняемыми файлами располагаются в каталогах с названием RPMS, а rpm-пакеты с исходными текстами - в подкаталогах SRPMS.

В Интернет rpm-пакеты можно найти на различных серверах. По моему опыту наиболее удобным сервером в Интернет для поиска rpm-архивов является сервер http://rufus.w3.org . На нем установлена поисковая система, которая позволяет упорядочивать список пакетов наиболее удобным для Вас способом:

• по именам пакетов;
• по дистрибутивам;
• по группам приложений;
• по датам;
• по поставщикам (производителям) ПО.

Общий объем архива rpm-пакетов на этом сервере составляет более 66 Гигабайт. Очень богатые архивы хранят также два ftp-сервера в России: ftp://ftp.chg.ru/pub/Linux и ftp://ftp.nc.orc.ru/

Необходимо только заметить, что если для перекачки пакетов из Интернет Вы используете компьютер, работающий под Windows, то все имена пакетов у Вас будут, скорее всего, искажены. Дело в том, что Windows "не любит" имена, в которых несколько точек (например, glib-1.0.6-3.i386.rpm и заменит "лишние", по его мнению, точки на подчеркивания - glib-1_0_6-3_i386.rpm). Так что после получения пакета (при переносе его на ПК с ОС Linux) надо эти "исправления" устранить, вернувшись к UNIX-вым именам.

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

Rpm -i имя_rpm-архива Если у Вас была установлена предыдущая версия пакета, то в простейшем случае надо дать команду следующего формата: rpm -U --force имя_rpm-архива Здесь параметр -U говорит программе, что надо произвести обновление (upgrade) пакета, а опция --force требует безусловно (и без лишних вопросов) обновить все входящие в пакет файлы. Заметьте, что это очень сильное требование, и в некоторых случаях может быть лучше сохранить какие-то (например, конфигурационные) файлы от предыдущей версии. Если установка проходит нормально, и никаких дополнительных сообщений не появляется, то после завершения работы программы (после появления приглашения shell) Вы можете пользоваться вновь установленным пакетом.

К сожалению не всегда все так просто. Приведу конкретный пример. У меня был установлен RedHat Linux версии 5.2, причем программа Midnight Commander (mc) была версии 4.1.36. На ftp-сервере я увидел версию 4.5.30 этой программы (пакет mc-4.5.30-12.i386.rpm) и, естественно, решил ее поставить. Однако оказалось, что для этого необходимо, чтобы были установлены еще 4 других пакета, о чем rpm мне и сообщила:

Ошибка: неудовлетворенные зависимости: redhat-logos нужен для mc-4.5.30-12 libglib-1.2.so .0 нужен для mc-4.5.30-12 libc.so.6(GLIBC_2.1) нужен для mc-4.5.30-12 libc.so.6(GLIBC_2.0) нужен для mc-4.5.30-12 Это и не удивительно, если Вы вспомните, что и при первоначальной установке Linux программа инсталляции тоже проверяла взаимозависимости пакетов и предлагала установить недостающие. Однако в случае инсталляции все необходимые пакеты находятся на том же диске, а здесь мне пришлось вначале поискать нужные пакеты. Два пакета (redhat-logos-1.0.5-1.noarch.rpm и glibc-2.1.1-6.i386.rpm) я нашел без труда, после чего rpm перестала просить и GLIBC_2.0. А вот с libglib.so .1 вышло сложнее. Во-первых я никак не мог найти пакета с таким названием. Как оказалось, такого пакета и не существует, файл libglib.so .1 входит в состав пакета glib-1.0.6-3.i386.rpm. Пока я это выяснил, я узнал также, что чтобы выяснить, какие файлы установит тот или иной пакет, надо дать команду rpm -qpl имя_rpm-архива а для получения информации о пакете - команду rpm -qpi имя_rpm-архива Дело в том, что файлы RPM кроме собственно архива файлов содержат информацию о пакете, включая имя, версию и краткое описание. С помощью той же программы rpm Вы можете просмотреть эту дополнительную информацию. Например, для пакета glib-1.0.6-3.i386.rpm получим следующие результаты: rpm -qpi glib-1.0.6-3.i386.rpm Вывод будет примерно таким: Name: glib Relocations: (not relocateable) Version: 1.0.6 Vendor: Red Hat Software Release: 3 Build Date: Суб 10 Окт 1998 04:49:03 Install date: (not installed) Build Host: porky.redhat.com Group: Libraries Source RPM: glib-1.0.6-3.i386.rpm Size: 55305 Packager: Red Hat Software < [email protected] > Summary: Handy library of utility functions Description: Handy library of utility functions. Development libs and headers are in gtk+-devel. Если дать команду: rpm -qpl glib-1.0.6-3.i386.rpm будет выдан список входящих в пакет файлов с указанием того, куда они будут установлены: /usr/lib/libglib.so.1 /usr/lib/libglib.so.1.0.6 RPM также предоставляет мощную систему запросов по установленным в системе пакетам. По команде rpm -qа Вы получите перечень всех установленных в системе пакетов (перечень будет очень большим, так что лучше сразу направить вывод в фильтр more). Вы можете искать информацию об отдельном пакете или об отдельных файлах. Например, Вы можете легко найти, какому пакету принадлежит файл и откуда появился: rpm -qf /etc/bashrc bash-1.14.7-16. Если Вы беспокоитесь о том, что случайно удалили важный файл из установленного пакета, просто проверьте это: rpm -Va Вы будете оповещены об любых аномалиях. Потом можно переустановить пакет, если это необходимо. Любые конфигурационные файлы будут сохранены.

RPM это очень полезная утилита, и, как Вы видите, имеет различные опции. Я привел только несколько примеров. Всего rpm имеет 16 основных режимов работы, которые имеет смысл объединить в 6 групп (после двоеточия приводится формат команды для соответствующего режима):

Запросы: Запрос: rpm [--query] Показать метки запросов (Querytags) : rpm [--querytags] Установка и поддержка установленных пакетов: Установка: rpm [--install] + Обновление: rpm [--freshen|-F] + Деинсталляция: rpm [--uninstall|-e] + Проверка: rpm [--verify|-V] + Подписи (пакеты подписываются электронной цифровой подписью в формате PGP, с целью обеспечения неизменяемости и сохранения авторства пакетов): Проверка подписи: rpm [--verify|-V] + Переподписывание: rpm [--resign] + Добавление подписи: rpm [--addsign] + Работа с базой: Инициализация базы: rpm -i [--initdb] Rebuild Database: rpm -i [--rebuilddb] Создание rpm-пакетов: Создать пакет: rpm [-b|t] + Перекомпилировать пакет: rpm [--rebuild] + Build Package from Tarball: rpm [--tarbuild] + Разное: Показать конфигурацию программы rpm: rpm [--showrc] Задать пользователей: rpm [--setperms] + Задать группы: rpm [--setgids] + Более подробное описание команды rpm Вы можете найти в RPM-HOWTO, страницах man и info. Здесь оно не приводится, в основном потому, что в графических режимах существуют несколько более удобные и "человечные" программы для управления установленным в системе ПО и процессами его обновления, которые и будут рассмотрены в следующих подразделах.

Примечание:

Я пользовался третьей версией RPM. В настоящее время существует уже версия 4, однако в списке рассылки blackcat-list промелькнуло такое сообщение:

> Кто-либо имеет опыт установки rpm 4.x? > Хотелось бы установить пакеты из состава дистрибутива Red Hat 7.0. Сам пан Каневский;-) не советовал ставить 4.х rpm-3.0.5-9.6x понимает структуру 4.х и ставит 4.х пакеты

Установка ПО из исходных текстов

В некоторых случаях исполняемые модули приложений могут поставляться и в виде tar-gz-архивов. В таком случае установка приложения только немного сложнее, чем в случае установки из rpm-пакета: необходимо просто развернуть архив и чаще всего можно уже запускать полученное приложение. Немного сложнее установить приложение, если оно поставляется в исходных текстах. Этот случай и рассмотрим в настоящем разделе.

Необходимые сведения о программировании на языке Си

Начать стоит с того, что операционная система UNIX родилась на свет одновременно с языком программирования C (Си). Более того, язык C был создан специально для разработки этой ОС, значительная часть UNIX была написана на языке С. ОС Linux тоже написана на Си. Поэтому, а также в соответствии с принципом свободного распространения исходных кодов, многие приложения для Линукс распространяются в виде текстов на С. Естественно, что для того, чтобы такое приложение установить в систему и запустить на исполнение, его необходимо скомпилировать. Для выполнения процедур компиляции обычно используется программа gcc (хотя существуют и некоторые альтернативные разработки).

GNU-компилятор с языка С gcc, содержит в себе 4 основных компонента, соответствующие четырем этапам преобразования исходного кода в исполняемую программу. Первый компонент - это препроцессор, который модифицирует исходный код программы перед компиляцией в соответствии с командами препроцессора, содержащимися в С-программе. В соответствии с этими командами выполняются простые подстановки текста. Второй - собственно компилятор, который обрабатывает исходный код и преобразует его в код на языке ассемблера. Третий компонент - ассемблер, который генерирует объектный код. И, наконец, четвертый компонент - компоновщик, который собирает исполняемый файл из файлов объектного кода. Дело в том, что большие программы обычно пишутся по-частям, в виде множества отдельных файлов, содержащих исходный код соответствующей части. Компилятор обрабатывает каждый такой файл отдельно и создает отдельные объектные модули (файлы таких модулей обычно имеют расширение.o). Создание единой исполняемой программы из таких модулей и является задачей компоновщика. При таком подходе, если в какой-то модуль программист вносит исправление, нет необходимости заново компилировать всю программу: достаточно откомпилировать исправленный модуль и заново запустить компоновщик.

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

Библиотеки бывают статическими, разделяемыми и динамическими. Статическая библиотека - это библиотека, код которой встраивается в программу при компиляции. Код разделяемой библиотеки не встраивается в программу, а загружается в память одновременно с программой и программа получает доступ к функциям этой библиотеки. Динамические библиотеки - разновидность разделяемых, только библиотечные функции загружаются в память только тогда, когда из программы поступит вызов соответствующей функции. В процессе выполнения программы они могут выгружаться и заменяться другими функциями из той же или другой библиотеки. Имена статических библиотек обычно имеют суффикс.a, а имена разделяемых библиотек - суффикс.so, за которым следует старший и младший номера версии. Имя может быть любой строкой, которая однозначно характеризует библиотеку. Обычно имена библиотек начинаются с lib. Примеры: libm.so.5 - общая математическая библиотека, libX11.so .6 - библиотека для работы с системой X Window. Библиотека libc.so.5 компонуется автоматически, в то время как большинство других библиотек необходимо явно указывать в командной строке при вызове программы gcc. Это делается через опцию -l за которой следует уникальная часть имени библиотеки, например, для вызова математической библиотеки достаточно указать -lm.

Многие системные библиотеки располагаются в системных каталогах, например, в /usr/lib/ и /lib/, но некоторые могут располагаться и в других каталогах. Список этих каталогов помещается в файл /etc/ld.so.conf. Каждый раз, когда разделяемая библиотека изменяется или инсталлируется вновь, нужно выполнять команду ldconfig, чтобы обновить файл /etc/ld.so.conf, а также ссылки на него. Если библиотека инсталлируется из RPM-пакета, это обычно делается автоматически, хотя и не всегда.

При компиляции больших программ, использующих фрагменты исходного кода, расположенные в разных файлах, бывает очень трудно отследить, какие файлы нужно перекомпилировать, а какие только компоновать. В таких случаях очень помогает утилита make, которая автоматически определяет, следует ли компилировать файл исходного кода, по дате его последней модификации. Утилита make оперирует файлами, исходя из их зависимости друг от друга. Эти зависимости определяются файлом с именем makefile. Строка файла makefile состоит из трех частей: имени целевого файла, списка файлов, от которых он зависит, и команды. Если какой-либо файл из списка изменился после целевого файла, то выполняется указанная в строке команда. В строке может быть указано несколько команд. Обычно команда - это вызов компилятора для компиляции файла исходного кода или компоновки файлов объектного кода. Строки, определяющие зависимости, отделяются друг от друга пустой строкой.

Инсталляция пакетов ПО из исходных текстов

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

Непосредственно процесс инсталляции пакета состоит из следующих шагов:

1. Перейти (с помощью команды `cd") в каталог, содержащий исходные коды устанавливаемого пакета.
2. Выполнить команду `./configure", которая осуществляет конфигурирование пакета в соответствии с Вашей системой. Процесс выполнения этой команды занимает довольно длительное время, причем команда выдает на экран сообщения, сообщающие, какие именно особенности системы испытываются.
3. Выполнить команду `make", для того, чтобы скомпилировать пакет.
4. После этого можно выполнить (это шаг не является обязательным) команду `make check", которая вызывает запуск процедур самотестирования, которые поставляются с пакетом.
5. Выполнить команду `make install" для установки программ, а также файлов данных и документации.
6. Заключительный этап состоит в выполнении команды `make clean", которая удаляет промежуточные объектные и двоичные файлы из каталога с исходными кодами. Для удаления временных файлов, которые создала команда `configure" (после чего пакет можно компилировать для другого типа компьютеров), надо выполнить команду `make distclean".

В большинстве случаев выполнение этой последовательности команд достаточно для установки нового пакета.

Сколько осталось места на диске

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

Программа rpm позволяет определить, сколько места потребуется для установки пакета: для этого надо дать запрос вида rpm -qpi имя_пакета и в строке Size будет выдано, сколько байт займет пакет. Осталось узнать, есть ли столько свободного места на диске.

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

Df -h Сведения о количестве свободного пространства на конкретном диске можно получить, если задать в качестве параметра имя файла устройства: df -h /dev/hda2 Если вместо имени файла устройства указать полное (с указанием пути) имя произвольного файла или каталога, то Вы получите данные о количестве используемого и свободного места в файловой системе, содержащей указанный файл (каталог).

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

Файлы (каталоги) удаляются в том случае, если они (размещенные в них файлы) Вам более не нужны. Естественно, что для удаления выбираются каталоги (или файлы) самого большого обьема и тут оказывается полезной команда du (disc usage).

Команда du позволяет узнать, сколько места занимает конкретный файл или подкаталог. Для этого надо дать команду следующего формата (в примере мы узнаем объем каталога /usr/lib)

Du -ks /usr/lib Результатом выполнения данной команды будет примерно такая строка 91418 /usr/lib которая означает, что каталог /usr/lib занимает 91418 килобайт (опция k указывает, что объем должен выдаваться в килобайтах). Опция s задана для того, чтобы выводился только суммарный объем каталога. Если Вы ее опустите, то получите данные об объеме каждого подкаталога и файла в указанном каталоге, а это очень много информации. Впрочем, последней строкой все равно будет выведен суммарный объем каталога, так что если Вас завораживает мелькание строк на экране, можете доставить себе это маленькое удовольствие.

Если маленькую s заменить на большую S, то выводиться будет только информация об объеме подкаталогов (но не файлов), что иногда тоже полезно. О других опциях указанных команд Вы можете узнать на соответствующих man-страницах или по команде info.

Теперь Вы знаете, как определить сколько места займет на диске устанавливаемый пакет и каков объем свободного пространства на диске. Рассмотрим, что можно сделать, если свободного места не достаточно. Надо заметить, что при стандартной инсталляции ОС Linux на диске образуется большое количество файлов, которые Вам вообще никогда не понадобятся. В то же время довольно трудно в огромной массе файлов найти те, которые Вам не нужны (тем более, что они спрятаны глубоко в дебрях структуры каталогов). Поэтому я расскажу вкратце о своем опыте поиска ненужных файлов, надеясь, что этот опыт окажется полезен читателю.

Освобождение дискового пространства

Однажды мне пришлось устанавливать Линукс (Black Cat 6.0) на 486-ой компьютер с жестким диском объемом 350 Мбайт. Хотя при установке я старался выбрать минимально возможную конфигурацию ПО, все равно после завершения установки диск оказался заполнен более чем на 90 %. Перечислю вкратце те действия, которые позволили мне освободить достаточно места на диске для установки новых пакетов.

1. Первым делом стоит подумать об удалении части пакетов ПО, установленных при инсталляции системы. Для того, чтобы решить, какой пакет или пакеты можно удалить, дайте команду: >rpm -qa --queryformat "%15{SIZE} %{NAME}\n" | sort -nr %rpm -q -a > packages Полученный файл packages будет содержать список всех установленных в системе пакетов ПО. Этот список можно проанализировать с целью выявления ненужных Вам пакетов и удалить таковые с помощью команды rpm с параметром -e. При этом будут удалены все созданные при инсталляции пакета файлы и каталоги. Этот способ самый безопасный, поскольку программа rpm предварительно проверит, не используется ли данный пакет какой-либо другой программой, и при наличии такой зависимости выдаст соответствующее предупреждение, а удалять что-либо откажется.

   У меня, например, в полученном таким образом файле packages встретилось упоминание пакета AfterStep-APPS-990329-2. Выполнив команду:

   % rpm -qi AfterStep-APPS выяснил, что этот пакет содержит некие апплеты к оконному менеджеру AfterStep. Поскольку такой менеджер не использовал, удалил этот пакет, а также и сам пакет AfterStep, с помощью команд: % rpm -e AfterStep % rpm -e AfterStep-APPS Это освободило около 5800 Кбайт (отмечу только, что удаление пакетов надо выполнять с правами root-а). Воспользовавшись таким приемом Вы можете удалить все пакеты, которые не используете. Я, например, удалил такие пакеты, как gnome-core, gnome-libs, gnome-audio, поскольку в качестве графической среды использую не Gnome, а KDE. Отмечу, что когда я попытался удалить gnome-core, rpm отказалась это сделать, сообщив, что часть этого пакета используется пакетом xmms-gnome. Еще больше неудовлетворенных зависимостей образуется при попытке удалить gnome-libs. Однако поскольку все упоминавшиеся в этих сообщениях пакеты так или иначе были связаны с Gnome, я рискнул удалить их все, а также другие пакеты, которые были с ними связаны. В результате освободилось около 7800 Кбайт дискового пространства.

2. Заглянув в каталог /usr/man, я обнаружил два подкаталога со страницами руководства man на французском и испанском языках. После их удаления освободилось около 100 Кбайт.
3. В каталоге /usr/lib/kbd/keymaps можно, по-видимому, удалить подкаталоги, в которых хранятся таблицы раскладок клавиатуры, предназначенные для других типов микропроцессоров, а в /usr/lib/kbd/keymaps/i386 -подкаталоги для раскладок, отличных от qwerty.

   Аналогичным образом удаляются раскладки клавиатуры для различных языков, которыми Вы не пользуетесь (зачем мне китайский или тайский, я не знаю на них ни одного слова!). Эти шрифты расположены в каталоге /usr/lib/kbd/keymaps/i386/qwerty.

   Можно попробовать удалить ненужные фонты из /usr/lib/kbd/consolefonts, однако если в начале таблицы раскладки клавиатуры указывается, для какого языка она служит, то о назначении файла фонта приходиться судить по его названию.

   Поскольку по умолчанию в системе устанавливаются средства локализации для различных стран (которые Вам, по-видимому, не потребуются), то можно удалить из каталога /usr/share/locale все подкаталоги, соответствующие не нужным Вам языкам. Всего там около 16 мегабайт, так что удаление ненужного может дать около 15 мегабайт освобожденного пространства. Еще более 2 мегабайт может дать очистка каталогов /usr/share/i18n/locales и /usr/share/i18n/charmaps

4. В каталоге /usr/share/doc/HTML/ имеются подкаталоги с документацией на разных языках, значительная часть которой Вам, по-видимому, не нужна. Я оставил в этом каталоге только три подкаталога en, ru default, причем последний является просто ссылкой на подкаталог en, так что фактически там только 2 подкаталога осталось. Удаление этой документации освободило около 500 Кбайт.

Пригодная для работы пользователя система состоит из множества (сотен и тысяч) программ и утилит. В Linux каждый компонент системы представлен в виде пакета . Все операции, связанные с изменением состава системы: установка, удаление, проверка, обновление компонентов, - производятся над пакетами. В целом, пакет - это средство сделать так, чтобы пользователь-администратор, изменяя или обновляя программное наполнение системы, работал не с файлами (имена которых ему подчас неизвестны), а с определёнными функциональностями самой системы: например, добавлял в неё не «500 файлов», а «WWW-сервер apache ».

Архив файлов

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

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

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

Нет жёсткого требования, чтобы один пакет содержал только одну программу. В пакет естественно объединять такие ресурсы, с которыми удобно работать как с одним целым. Это может быть отдельная программа или набор утилит (например, coreutils , основные утилиты, унаследованные Linux от UNIX) или модуль с дополнительными возможностями программы, или общие для нескольких программ ресурсы. В процессе развития и/или устаревания программного обеспечения выделение некоторых задач в отдельный пакет может приобретать или терять смысл, поэтому способ объединения ресурсов в пакеты - это не что-то раз и навсегда выбранное: пакеты могут разделяться и сливаться.

Самый простой и традиционный для Linux способ объединить несколько файлов в один - использовать утилиту tar .

tar появился намного раньше Linux и изначально служил для создания файловых архивов на магнитной ленте. Отсюда и его название - t ape ar chiver, «архиватор для (магнитных) лент». В настоящее время tar присутствует в любой UNIX-подобной системе и позволяет работать с файловыми архивами на любых носителях.

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

Methody@localhost:~ $ tar -cf methody.progs.tar bin/ methody@localhost:~ $ tar -tf methody.progs.tar bin/ bin/loop bin/script bin/to.sort bin/two

Пример 1 . Создание файлового архива при помощи tar

Первый параметр tar состоит из двух частей: операция, которую следует произвести над архивом, в данном случае « c » (c reate, создать), и ключ « f », который указывает, что архив следует создать в файле, имя файла архива - следующий параметр. Имя архива может быть любым, но Гуревич посоветовал снабдить его расширением « .tar », чтобы потом не путаться. После имени архива следуют имена файлов и каталогов, которые следует запаковать.

С каждым указанным каталогом tar работает рекурсивно, т. е. запаковывает все содержащиеся в нём файлы и подкаталоги.

Чтобы проверить, какие файлы попали в архив, Мефодий просмотрел содержимое получившегося архива командой « tar -tf имя_архива » (« t » - просмотреть, « f » использовать файл, указанный следующим параметром). Тут Мефодий обратил тут внимание на два обстоятельства. Во-первых, в архиве имена файлов сохранились вместе с путём. Во-вторых, все пути, сохранённые в архиве - относительные.

При распаковке архива tar файлы извлекаются вместе с путём, недостающие подкаталоги создаются по мере необходимости. Все пути tar считает относительными от своего рабочего каталога. Если теперь Мефодий распакует свой архив (командой « tar xf имя_архива »), то в рабочем каталоге будет создан подкаталог « bin/ » и в него будут записаны все файлы из архива.

Methody@localhost:~ $ tar -xvf methody.progs.tar bin/ bin/loop bin/script bin/to.sort bin/two

Пример 2 . Распаковка архива

Ключ « v » велит tar быть «разговорчивым» (verbose), т. е. выводить больше диагностичских сообщений, блаодаря этому tar при распаковке выводит имена (с путём) всех записываемых файлов. Если в рабочем каталоге уже есть файл, который tar собирается создать при распаковке, то этот файл будет попросту заменён файлом из архива. Так, когда Мефодий распаковал свой архив, подкаталог « bin/ » со всем его содержимым заменился на подкаталог из архива. В данной ситуации это не страшно, поскольку в архиве файлы такие же, но вот если бы Мефодий перед распаковкой изменил какие-то из своих файлов в « bin/ », он лишился бы всех изменений.

Формат пакета

Помимо хранения архива файлов у пакета есть и другие задачи (они обсуждаются в двух следующих разделах), поэтому для пакета в Linux не очень подходит обычный файловый архив, наподобие.tar , а нужен специальный формат. Таких форматов в Linux бывает несколько (краткое перечисление и характеристика - в разделе Package.Установщики пакетов), в системе Мефодия используется один из наиболее распространённых - rpm , поэтому все примеры в данной лекции будут с его участием. Для работы с пакетами в специальном формате нужна специальная программа-установщик, которая так же и называется - rpm: она занимается установкой, удалением, обновлением и проверкой пакетов.

Пакет в формате rpm - это единый файл со всеми необходимыми данными. Существуют определённые (хотя и не очень жёсткие и последовательные) соглашения относительно названий файлов-пакетов. Например, rpm -файл, содержащий комплект стандартных утилит coreutils , в системе Мефодия называется coreutils-5.2.1-some5.rpm: сначала - имя пакета , затем через дефис - служебная информация о номерах версий программного обеспчения и самого пакета.

Регистрация в системе

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

Чтобы предупреждать конфликты, в системе должна храниться информация обо всех уже установленных пакетах и принадлежащих им файлах. Когда точно известно, какие файлы принадлежат пакету, можно полностью удалить пакет, не оставив и не удалив при этом ничего лишнего. Такой подход препятствует образованию в системе «мусора» - бесполезных файлов, оставшихся от удалённых программ - и делает операцию установки/удаления пакета полностью обратимой.

Rpm хранит информацию обо всех установленных в системе пакетах и принадлежащих им файлах и может выдать эту информацию по запросу пользователя. Почитав руководство по rpm , Мефодий выяснил, что список всех установленных в системе пакетов (скорее всего, очень длинный, в несколько тысяч строк) можно получить командой « rpm -qa », список всех файлов, принадлежащих пакету, командой « rpm -ql имя_пакета ». Он решил проверить, есть ли в его системе уже известный ему по предыдущим лекциям пакет coreutils и узнать, какие утилиты ему принадлежат:

Methody@localhost:~ $ rpm -qa | grep coreutils coreutils-5.2.1-some5 methody@localhost:~ $ rpm -ql coreutils | grep bin /bin/basename /bin/cat /bin/chgrp /bin/chmod

Пример 3 . Какие файлы принадлежат пакету?

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

Можно выполнить и обратную процедуру - выяснить про любой файл, какому пакету он принадлежит:

Methody@localhost:~ $ rpm -qf /etc/passwd setup-2.2.5-some1

Пример 4 . Какому пакету принадлежит файл?

Файлы, принадлежащие пакету, могут быть не только удалены, но и изменены. Это может быть сделано сознательно (например, отредактирован конфигурационный файл), в таком случае при обновлении или удалении пакета изменённый файл нужно сохранить, потому что в нём содержится результат работы, проделанной администратором. Для этого система должна уметь определять, что принадлежащий пакету файл изменился. Для этого в пакете должна храниться информация обо всех файлах архива: размер, атрибуты, контрольная сумма - в этом случае процедура проверки сможет проверить соответствие атрибутов файла в пакете атрибутам установленного в системе файла. Мефодий может проверить, что изменилось в пакете командой « rpm -V имя_пакета ».

Methody@localhost:~ $ rpm -V setup S.5....T c /etc/X11/fs/config S.5....T c /etc/exports S.5....T c /etc/fstab S.5....T c /etc/printcap ..?..... c /etc/securetty

Пример 5 . Что изменилось в пакете?

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

Система Linux раскладывается на компоненты без остатка: каждый файл в Linux принадлежит какому-нибудь (и только одному!) пакету.

Естественно, кроме тех файлов, которые созданы пользователями.

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

Изменение настроек системы

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

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

• выполнение предшествующих установке/удалению сценариев;
• копирование файлов из архива в систему или удаление файлов из системы
• выполнение следующих за установкой/удалением сценариев.

Methody@localhost:~ $ rpm -q --scripts coreutils preinstall scriptlet (through /bin/sh): # Remove info pages from fileutils, textutils and sh-utils. for f in /usr/share/info/{fileutils,textutils,sh-utils}.info*; do [ -f "$f" ] || continue RPM_INSTALL_ARG1=0 /usr/sbin/uninstall_info "$f" ||: done postinstall scriptlet (through /bin/sh): /usr/sbin/install_info coreutils.info preuninstall scriptlet (through /bin/sh): /usr/sbin/uninstall_info coreutils.info

Пример 6 . Просмотр сценариев в пакете

Мефодий выяснил, что сценарии в пакете coreutils запускаются перед началом установки (preinstall), после установки (postinstall) и перед удалением (preuninstall), они выполняются стандартным командным интерпретатором (/bin/sh). Все эти сценарии нужны для того, чтобы зарегистрировать в системе info установленную пакетом документацию или удалить эту документацию из системы (командами /usr/sbin/install_info и /usr/sbin/uninstall_info соответственно). Поскольку info строит общее оглавление всей имеющейся в системе документации, простого копирования файлов было бы недостаточно.

В результате подобных операций по интеграции пакета в систему могут быть изменены или удалены файлы, не принадлежащие данному пакету, созданы новые файлы. Если программа, содержащаяся в пакете, пользуется услугами какой-нибудь уже установленной службы (например, syslogd), может понадобиться регистрация этой программы в конфигурационных файлах службы. Конечно, изменение «чужих» файлов в процессе установки пакета нежелательно: впоследствии, удаляя пакет, потребуется вернуть файл в исходное состояние, что не всегда возможно (например, после вдумчивого редактирования администратором). Избежать редактирования конфигурационных файлов позволяет схема «. d», описанная в лекции Этапы загрузки системы .

Цена удобства

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

Функции по созданию пакета в формате rpm также выполняет программа rpm .

Узнать, кто и когда создал пакет, получить краткую справку о программном обеспечении, которое в нём содержится, можно командой « rpm -qi имя_пакета ».

Methody@localhost:~ $ rpm -qi setup Name: setup Relocations: (not relocateable) Version: 2.2.5 Vendor: Some Linux Team Release: some1 Build Date: Чтв 29 Янв 2004 18:08:05 Install date: Пнд 23 Авг 2004 15:08:45 Build Host: shogun.somelinux.org Group: Система/Настройка/Прочее Source RPM: setup-2.2.5-some1.src.rpm Size: 39969 License: GPL Packager: Leon B. Gourievitch Summary: Initial set of configuration files Description: Initial set of configuration files to be placed into /etc.

Пример 7 . Описание пакета

Нужно принимать во внимание, что любой пакет, содержащий программное обеспечение для Linux, не является универсальным. Если у вас есть такой пакет, это ещё не означает, что его можно установить в вашей системе. Дело в том, что разные дистрибутивы Linux различаются именно тем, каким образом программное обеспечение организовано в систему (о дистрибутивах речь пойдёт в лекции ). Дистрибутивы могут различаться размещением файлов и процедурами, предусмотренными для интеграции в систему программного обеспечения, не говоря уже о том, что в разных дистрибутивах используется разный формат пакетов. Это значит, что пакет, подготовленный с ориентацией на один дистрибутив, может оказаться несовместимым с другим. Чтобы в вашем дистрибутиве появилась некоторая программа, кто-то должен подготовить и сделать доступным соответствующий пакет.

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

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

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

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

Автор: David M Williams
Дата: 16 января 2008
Свободный перевод: Алексей Дмитриев
Дата перевода: 24 января 2008

Ищете приложения с открытым исходным кодом? Дистрибутивы Линукс имеют давнюю традицию упаковывать программы в легко устанавливаемые пакеты. Однако поиск самих этих пакетов отнюдь не всегда интуитивно понятен, да и находятся они не всегда в желаемом виде. Эта статья о том, как выжать максимум из Линукс пакетов.

Первое место, где надо искать - это ваш дистрибутивный набор CD или DVD. Все дистрибутивы Линукс, кроме "самых маленьких", содержат гораздо больше программ, чем обычно установлено. Когда вы устанавливаете дистрибутив, вы имеете выбор типа устанавливаемой системы, который зачастую сводится к выбору между рабочей станцией и сервером. В зависимости от выбора, устанавливаются соответствующие наборы пакетов.

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

И тут на помощь приходит Интернет. Зайдите на великие сайты открытых исходников, такие как FreshMeat или . Просмотрите их в поисках новых интересных приложений.

Не все всегда просто, даже если вы нашли нечто подходящее: возьмите хоть для примера. Это мощная система позволяет оперировать содержимым вэб-сайтов и интранет содержимым, посвященным открытым исходникам - звучит очень круто. Она создана, чтобы позволить технически неподготовленным пользователям создать и поддерживать их собственные он-лайн проекты безопасно, профессионально и недорого. Это ваше классическое LAMP приложение, написанное на PHP и использующее Apache и MySQL.

Между тем, MySource Classic доступен для скачивания в двух форматах: как.zip файл, или как.tar.gz файл. Оба формата являются архивными. Почти все знают, что такое zip файл, в то время как.tar.gz (также встречающийся как.tgz) - это чисто Linux/UNIX специфичный формат, известный под именем тарбалл.

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

Запустите терминал и, с помощью команды tar, просмотрите архив; как и везде в Линукс, тут существует несколько опций.

Вы можете разархивировать тарбалл при помощи команды gunzip:

gunzip mysource-2.16.2.tar.gz

Это создаст новый файл под названием mysource-2.16.2.tar, исследуйте его содержимое при помощи:

tar -tvf mysource-2.16.2.tar | more

Содержимое теперь стало видно. Есть другой способ просмотреть содержимое тарбалла, не разархивируя его, при помощи другого варианта той же команды tar:

tar -tzvf mysource-2.16.2.tar | more

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

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

Итак, распакуем его. Снова применим tar:

tar -xf mysource-2.16.2.tar

Или, как раньше, минуя стадию gunzip, добавим опцию -z:

tar -xzf mysource-2.16.2.tar.gz

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

Тарбаллы - наиболее распространенный формат архива, но не единственный; иногда вы можете встретить cpio архивы, которые заканчиваются расширением (суффиксом) .cpio. Такой формат обычно применяется внутри rpm пакетов, сам по себе почти не встречается. Но, коли вы встретитесь с таким форматом, то учтите, что, хотя команда cpio и имеет схожие опции с командой tar, cpio работает на входе и выходе потоков (конвейеров), а не файлов, так что, чтобы просмотреть архив смело пишите:

cpio -tv < examplefile.cpio

а чтобы распаковать содержимое архива:

cpio -i -d < examplefile.cpio

Когда тарбалл получен и распакован, ваша задача скомпилировать и установить программу. Этот формат наиболее универсален и не зависит от типа вашего дистрибутива. Есть хорошая вероятность, что приложение установится, при условии, что вы знаете, что делаете. К счастью "знаете что делаете" обычно сводится к серии из трех команд:

./configure
make
make install

при условии, что разработчик был столь любезен, что предоставил инструмент для конфигурации и Makefile.

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

Два наиболее обычных формата пакетов суть: Debian пакеты и RPM пакеты. Первый формат используют такие дистрибутивы как Debian, Ubuntu, Knoppix и некоторые другие; RPM формат применяется в Red Hat, Fedora, Suse и некоторых других.

Ели только вы не создаете собственный дистрибутив Линукс, выбор менеджера пакетов уже сделан за вас. Я всегда подчеркивал, что разница между дистрибутивами Линукс состоит, в основном, в том, какой менеджер пакетов используется, и какой набор пакетов устанавливается по умолчанию. В самом деле, все версии Линукса используют одинаковые ядра, практически одинаковые инструменты GNU tools - но главное различие дистрибутивов - менеджер пакетов.

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

На крайний случай, возможно извлечь все файлы из пакета, а затем вручную установить их. Как говорилось ранее, формат RPM пакетов использует внутри себя формат архива cpio. Простая команда rpm2cpio поможет разархивировать внутренний архив. Для того чтобы извлечь все файлы из пакета, не устанавливая его, применяйте команду:

rpm2cpio examplepackage.rpm | cpio -i

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

Извлекайте содержимое пакета Debian следующим образом:

ar -x examplepackage.deb

Это приведет к появлению двух тарбаллов: control.tar.gz и data.tar.gz, плюс одного текстового файла: debian-binary.

Файл debian-binary содержит одну строку - это просто название версии использованного при создании пакета упаковщика. Тарбалл control.tar.gz содержит инсталляционные скрипты и полезную информацию; тарбалл data.tar.gz содержит двоичные и конфигурационные файлы, все файлы, необходимые программе для работы. При острой необходимости вы можете открыть этот архив командой tar -xf, хотя, если приложение сложное, вы зададите большую работу инсталляционным скриптам.

Чуть выше, я уже говорил, что одно из замечательных свойств менеджера пакетов является его способность регулярно обновлять ваши приложения до новейших версий. Используемые для этого инструменты варьируют в зависимости от дистрибутива, но проверьте, нет ли у вас: Apt (Advanced Package Tool - Усовершенствованный Пакетный Инструмент), Yum (Yellowdog updater modified - модифицированный обновитель ЖелтаяСобака), Synaptic (графическое расширение Apt) и up2date.

Apt - это старая добрая программа, которая родом из Debian и родственных дистрибутивов, но теперь поддерживает и RPM. Это не столько единый инструмент, сколько набор утилит; чаще других используются apt-get, который скачивает пакеты с репозиториев, и apt-cache, который выясняет, что, собственно говоря, нужно скачать. Synaptic не предлагает новых функций, но объединяет все вместе в удобном графическом интерфейсе.

Подобно Apt"у, Yum - это утилита командной строки для RPM пакетов. Она может выяснить, что доступно, установить пакеты, и производить другие действия, типа листинга установленных пакетов и удаления старых версий пакетов.

Программа up2date также работает с RPM пакетами, но она обеспечивает доступ сразу и к Yum и Apt репозиториям, предоставляя тем самым больший выбор.

Так выходите он-лайн, устанавливайте свободный софт, используйте Свободные Операционные Системы.

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

Как Вы наверняка знаете и помните, я обещал потихоньку (по вашим просьбам) охватывать цикл Linux , знакомя Вас с разными основами и очень постепенно перетекая из теории в практику.

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

Вся эта огромная куча пакетов с их ворохом зависимостей друг от друга, управляемая пакетным менеджером, как раз и составляет Ваш дистрибутив Linux . Но это не просто куча мусора, а упорядоченная система, которая называется - та-дам! - репозитории пакетов программ. Круг замкнулся – мы вернулись к первому понятию – что такое репозиторий :)

Несколько слов о нюансах

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

1. Не надо искушать судьбу и ставить программы в Linux в обход менеджера пакетов, простой компиляцией.Работать они будут, но пакетный менеджер ничего о них не будет знать, из-за чего при обновлении системы или программ Вы рискуете получить больше проблем на свою голову, чем представляете. Устанавливайте программы только в виде пакетов.
2. Не надо подключать те репозитории, о которых имеете совсем смутное представление. Например, не надо подключать репозитории со словами testing , debug и тому подобными терминами, ибо эти репозитории в первую очередь предназначены для самих разработчиков дистрибутивов и далеко не всегда стабильны.
3. Не подключайте подряд все доступные репозитории, это тоже может сыграть с Вами злую шутку. Подключайте только самые необходимые, не надо жадничать:)

Например, при установке операционной системы Fedora по умолчанию сразу подключены два репозитория:

• Fedora (пакеты, которые подходят на любую комбинацию из компакт-дисков или DVD-дисков)
• Updates (обновленные пакеты, новее, чем репозиторий (хранилище) Fedora)

Для нормальной работы нужно подключить дополнительный репозиторий rpmfusion (без него Вам действительно не обойтись), что даст доступ к программам, которые не могли быть включены в дистрибутив из-за лицензионных ограничений (приложения, которые требуются для , таких как mp3 , dvd и т.д.; – к ним относятся проприетарные драйвера для ATI и NVIDIA ; игры: Bub"s Brothers, Secret Maryo Chronicles, UFO: Alien Invasion, Wörms of Prey, xrick, GLtron и многие, многие другие; эмуляторы: эмулятор Commodore 64 , а также Commodore 8 bit , эмулятор Amiga, Nestopia, ZSNES и много других). Чтобы подключить этот репозиторий, достаточно в командной строке (терминале) от суперпользователя () ввести команды:
$ sudo rpm -ivh https://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-stable.noarch.rpm
$ sudo rpm -ivh https://download1.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-stable.noarch.rpm
Обратите внимание, что репозиторий rpmfusion разделяется на две части: free и nonfree . Первый содержит чисто свободные программы в понимании FSF , распространяемые под GPL и совместимыми с ней лицензиями. Содержимое второго, вопреки названию, - также программы по преимуществу свободные, но попадающие под пресловутые патентные ограничения некоторых государств (например, аудио- и видеокодеки).

То же самое касается и менеджера пакетов в Fedora . Для нормальной и удобной работы менеджера пакетов (yum) в Fedora рекомендуется подключить дополнительный плагин fastestmirror . Этот плагин очень важен: он определяет не просто ближайшее зеркало, как это делают аналогичные утилиты из других систем управления пакетами, а устанавливает именно самое быстрое зеркало в данный момент – по времени отклика.
$ sudo yum install yum-plugin-fastestmirror
В двух словах как-то так:)

Послесловие

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

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

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

P.S. За существование данной статьи спасибо члену команды Pantera