Материал из eSyr's wiki.

Версия 14:53, 25 июня 2008 (править) ESyr01 (Обсуждение | вклад) (→Где искать ответы на вопросы (?) о_О) ← К предыдущему изменению		Версия 12:01, 8 августа 2008 (править) (отменить) 80.251.129.165 (Обсуждение) (→Конфликты версий) К следующему изменению →
Строка 108:		Строка 108:
	==== Конфликты версий ====		==== Конфликты версий ====
	о_О		о_О
		+	кто здесь ?
	=== Установщик пакетов ===		=== Установщик пакетов ===

---

Версия 12:01, 8 августа 2008

Содержание 1 Установка и настройка ПО 1.1 Поиск ПО: где брать? 1.1.1 Дистрибутив и репозиторий 1.1.2 Другие варианты 1.1.3 Рецепт: как искать программы под Linux 1.2 Установка ПО 1.2.1 FHS 1.2.2 Пакет 1.2.2.1 Зависимости 1.2.2.2 Конфликты 1.2.2.3 Конфликты версий 1.2.3 Установщик пакетов 1.2.4 Менеджер пакетов 1.2.5 Установка ПО из своего дистрибутива 1.2.6 Установка ПО не из своего дистрибутива 1.2.6.1 Установка из хранилища 1.2.6.2 Установка из другого репозитория 1.2.6.3 Сборка из исходных кодов 1.2.6.4 Установка бинарника 1.2.6.5 Резюме 1.3 Настройка 1.3.1 Текстовые конфигурационные файлы 1.3.2 Конфигураторы 1.4 Где искать ответы на вопросы

Установка и настройка ПО

Поиск ПО: где брать?

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

Приходит человек и говорит: «У меня вот Photoshop, а что у вас в Линуксе есть?». Ему, как правило, отвечают: «А у нас есть GIMP». После чего человек уходит, а через некоторое время возвращается и говорит, что в GIMP нет ничего из того, что ему надо. Это самый плохой подход — подход от названия.

Более сложный и обстоятельный способ — подход от инструмента. Он популярен у людей, которые в определённой мере ориентируются в предметной области. В данном примере, поскольку Photoshop — программа, связанная с графикой, можно рассмотреть инструменты, связанные с графикой. Выделяют два основных вида графики -- векторную и растровую. Векторная графика, в свою очередь, делится на плакатную, макетную и диаграммы. Для плакатной графики используются Inkskape, Xara Xtreeme, Kontour и ещё добрый десяток различных приложений. Про печатные макеты можно прочитать на Википедии, и, например, узнать, что программы на PostScript редактировать не надо (PostScript -- это язык. На нём даже вирус можно написать). Для работы с диаграммами есть Dia, Xfig, OpenOffice.org Draw. Что касается растровой графики, то есть программы для обработки фотографий — GIMP, Krita. Есть аналоги MS Paint — их бесконечно много, один хуже проще другого. Из них можно вспомнить Tux Paint, Kolourpaint. Также существуют пакетные преобразователи, позволяющие писать разнообразные скрипты, преобразующие картинки. Ярким примером подобного инструмента является ImageMagick. Можно вспомнить ещё про 3D-графику — Blender, POV-RAY. При таком подходе на пришедшего с вопросом человека в итоге сваливается 200 названий, человек уходит,а когда возвращается, говорит, что Linux ужасно крут, но не умеет делать то, что ему надо.

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

Таким образом, получаем три подхода:

• от названия
• от инструмента
• от задачи

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

Откуда вообще берутся программы под Linux? Надо дать достаточно точный и полный ответ, ибо обычно ответ звучит как «лежат на диске» или «скачиваются из сети». Рассмотрим то, где на самом деле берут ПО для Linux.

Дистрибутив и репозиторий

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

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

Другие варианты

Не исключена ситуация, при которой нужного приложения в используемом репозитории не оказывается. Так как хранилищ существует несколько, то при отсутствии искомой программы в том хранилище, на котором базируется используемый вами дистрибутив, можно попробовать поискать в других репозиториях. Где ещё можно попытаться найти интересующее ПО: существуют специализированные сайты, такие как SourceForge.net, где разработчикам предоставляются средства для ведения разработки, а пользователям — средства поиска по имеющимся проектам. Кроме этого, существуют независимые сайты разработчиков, где программы могут распространяться как в виде исходных текстов, так и в собранном виде.

Рецепт: как искать программы под Linux

В результате выстраивается некая схема поиска ПО:

• Искать в дистрибутиве
• Искать в репозитории
• Искать в чужом дистрибутиве.
• Поиск по специализированным сайтам (sourceforge, savanna, freshmeat)
• Поиск в google на предмет сайта разработчика
• Если всё это проделали, и результатов нет, то не значит, что приложения не существует. Очень хороший источник информации — сообщество.
  • Официальные информационные ресурсы (документация, сайт, wiki)
  • Списки рассылки
  • IRC, форумы

  Сообщество на последнем месте (несмотря на свою достаточно высокую эффективность) потому, что до этого на поиск тратятся только собственное время, а в сообществе тратят своё время другие люди.

Установка ПО

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

• Установка из чужого дистрибутива/репозитория
• Сборка из исходных кодов
• Бинарный инсталлятор

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

FHS

В Linux существует строгая иерархия каталогов (File Hierachy System, FHS), которая описывает структуру каталогов и их семантику. Подробно FHS описан в учебнике Курячего Г. В. «Операционная система Linux». Так, в соответствии с FHS, существует 4 места для ПО, 2 каталога для разделяемых библиотек, 1 каталог для документации, и так далее. Каждая программа, состоящая из многих файлов, размещает их в соответствии с их предназначением в соответствующие каталоги в ФС.

Пример размещения некоторых типичных файлов абстрактной программы:

• /usr/bin/prog — исполняемый файл программы
• /usr/share/doc/prog/README — файл-описание программы
• /usr/share/man/1/prog.tgz — страница руководства по программе

И всё это входит в один программный продукт.

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

Пакет

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

Пакет — файл, содержащий всё необходимое для установки и удаления программного продукта.

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

Рассмотрим подробно, что представляет собой пакет:

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

В связи с этим возникает ряд вопросов:

• Как разрешать зависимости одних пакетов от других?/*что такое зависимости нигде не сказано, а уже их разрешают. Тогда уж просто пункт обозвать «Зависимости тратата»*/
• Как разрешать конфликты, то есть, те случаи, когда при попытке установить файл из архива оказывается, что такой файл есть, и создан он не пользователем, а другим пакетом?

Зависимости

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

Разделяемая библиотека — самостоятельный набор библиотек, используемый другими программными продуктами.

Преимущества использования разделяемых библиотек:

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

Но, при всех достоинствах разделяемых библиотек, появляется проблема -- задача разрешения зависимостей. Разделяемые библиотеки не входят в пакет. Каждая группа библиотек находится в отдельном пакете. Перед установкой программного продукта необходимо установить все библиотеки, которые им используются, то есть, удовлетворить его зависимости. Получается палка о двух концах: с одной стороны, использование разделяемых библиотек упрощает и ускоряет разработку; с другой стороны, усложняется порядок установки программ — необходимо скачать и установить в правильном порядке всё дерево (точнее, ациклический орграф) зависимостей. В большинстве дистрибутивов Linux для автоматизации удовлетворения зависимостей существуют две программы — установщик и менеджер пакетов, которые подробно рассмотрены далее.

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

Конфликты

Иногда при установке очередного пакета может возникнуть так называемый конфликт.

Конфликт — ситуация, при которой файлы из разных пакетов должны иметь одинаковые абсолютные имена/*абсолютное имя – откуда термин?не лучше ли «полностью одинаковые имена и пути»*/.

Пример конфликта: пакеты с различными вариантами vi: vi, vim-minimal, mvi пытаются установить бинарный файл /usr/bin/vi.

Существует метод, позволяющий разрешать конфликты — альтернатива. Для каждого пакета выбираются свои уникальные имена (в данном примере — /usr/bin/vi.original, /usr/bin/vim, /usr/bin/mvi). Кроме этого, создаётся файл с конфликтным именем (/usr/bin/vi), но он является символической ссылкой на один из файлов, боровшихся за данное имя. То, куда будет указывать символическая ссылка, решается при помощи отдельного механизма(например назначением пакетам некоторых весов и ссылкой на файлы пакета с наибольшим весом).

Конфликты версий

о_О кто здесь ?

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

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

Установщик — утилита, которая позволяет управлять отдельным пакетом. Сюда входят установка и удаление, проверка пакета на различные свойства, просмотр различий в версиях пакета, проверка зависимостей, и так далее.

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

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

!!! Тут переход от определений к тому, откуда ставить, и что за это будет

Установка ПО из своего дистрибутива

В рамках дистрибутива всё будет хорошо.

Установка ПО не из своего дистрибутива

Установка из хранилища

Когда вы обращаетесь к хранилищу, может случиться, что появились версии программ и все поменялось. В этом случае применим следующий способ: помимо rpm есть src.rpm, в котором содержится всё необходимое для сборки программного продукта. Можно скачать src.rpm и пересобрать его в своём окружении. Всё сводится к выполнению новых команд:

• Скачать src.rpm
• Собрать. Образуется бинарный rpm
• У нового бинарного rpm не будет проблем с зависимостями

Установка из другого репозитория

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

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

Сборка из исходных кодов

Существует два основных способа: сборка с использованием вручную написанного makefile и сборка с использованием autotools. Основная проблема в том, что если активно пользоваться программой, то при каждой новой версии выполняется последовательность команд configure, make, make install, в результате чего возникает большое количество версий одних и тех же библиотек, удалить которые нельзя, так как их может использовать кто-то ещё. Кроме того, может получиться, что старые библиотеки используются вместо новых.

Установка бинарника

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

В общем случае не рекомендуется пользоваться бинарными инсталляторами. Правильно сделанные инсталляторы выполняют установку в соответствии с FHS, то есть, производят установку одним из нижеуказанных способов:

• В самом лучшем случае делается следующее: в /opt/ (в который ставятся программы вне дистрибутива) будет /opt/(program name)/{bin, lib, ...} Единственная проблема разработчиков --- заставить запускаться бинарник оттуда. Поэтому даже в этом случае он создаст в /usr/bin/ специальный файл для запуска приложения (это плохо тем, что в стандартом каталоге будет файл, не принадлежащий ни одному пакету).
• Чуть менее хороший вариант — установка в /usr/local/{bin, lib, ...}. /usr/local/ — то, что живёт только на вашей системе и должно быть сохранено после удаления системы и установки новой. Чем это плохо — может возникнуть конфликт имён. Чем это лучше — /usr/local/ обычно есть в PATH и установщик больше нигде файлы создавать не будет.

И то, и другое должно происходить от имени суперпользователя, что потенциально порождает проблемы (как и в любом другом случае установки ПО, но данный усугубляеется тем, что нельзя проконтролировать процесс). Как альтернатива, существуют директории ~/bin и ~/.local, в которые можно произвести инсталляцию, не имея прав root'а, но отнюдь не всегда эти пути прописаны в PATH./*мб все таки пояснить что такое PATH и почему там все должны быть прописаны? сноской.*/

Резюме

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

Настройка

Это довольно нетривиальный и важный вопрос, рассмотрим основные темы, с этим связанные:

• Пространство имён. Необходимо настраивать всю систему целиком, следовательно, должен быть такой способ именования настроек, что в нём было бы легко ориентироваться. Например, единая древовидная структура — пример плохой организации
• Гибкость формата представления настроек. Например, если жёстко задана древовидная структура, то в такой структуре отпадает организация в виде графа (tags),или в виде программы; они/*что за таинственные они?граф управляет системой?о_О*/ тоже могут быть штуками, которые управляют системой. То есть, в рассматриваемом пространстве имён необходимо предусмотреть возможность нахождения данных произвольной структуры
• Удобный инструментарий для чтения и модификации. В случае с настройкой разумно рассматривать критерий человекоприемлемости: кусок данных можно назвать человекиприемлемым, если человек может его написать с нуля.

Текстовые конфигурационные файлы

В Linux до сих пор это/*надо конкретизировать «это»*/ решается старым, UNIX-way, способом: любой файл, с которым возможна работа пользователя — человекочитаемый текст. Опишем, как это выглядит:

• Пространство имён — файловая система. Зачем множить сущности (дерево), если дерево уже есть. В /etc/ лежат файлы, необходимые для настройки остальной части системы
  • Каждый файл принадлежит пакету, и названия в etc соответствуют названиям пакетов. Это способ локализации информации о настройках
• Гибкость представления. Файлы настройки могут иметь произвольные синтаксис и семантику: пары ключ-значение, XML-файлы, скрипты.
• Чтение и модификация. С одной стороны, есть графические программы настройки (подробнее про них далее). В каком-то смысле они удобные. Но графический интерфейс хорошо подходит для настройки графического интерфейса и стандартных типовых задач. А каковы должны быть инструменты, которые бы позволили читать и изменять практически любой конфигурационный файл, учитывая его произвольные синтаксис и семантику? Поскольку мы договорились, что конфигурационные файлы представляются в виде текста, то у нас есть способ работы с ними — текстовый редактор (в случае, если не стоит задач автоматизации работы). Но редактор конфигурационных файлов должен обладать не совсем таким набором возможностей, каким должен обладать редактор текста. При редактировании литературного текста обычно необходимо уметь проверять орфографию, писать и писать, и потом, в конце, возможно, переставить пару абзацев. Тогда как при работе с конфигурационными файлами элементы разметки и другие синтаксические единицы служат объектами оперирования. Типичный способ работы состоит в том, что находится необходимая секция, в которой хранится свойство, и оно изменяется. Поэтому редактор файлов настроек, должен уметь быстро производить поиск, ручную и авотматизированную модификацию. Типичный пример: заменить имя хоста во всех конфигурационных файлах. Почему бы это не оформить в виде парсера? Некоторые задачи можно решить вручную, но некоторые задачи можно решить автоматизированно, и лучше, чтобы таких задач было как можно больше. И в таких случаях нужны процессоры обработки текста.

Яркими примерами инструментов для работы с текстовыми файлами вообще и с конфигурационными файлами в частности являются такие программы, как vim и emacs. Но перед тем, как с ними работать, необходимо сначала научиться ими пользоваться. Для случае же, когда нужно работать сразу, есть такие программы, как nano, mc, kate, evim.

Конфигураторы

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

• Настройка каких-либо графических приложений (KDE Control Center, который в первую очередь настраивает KDE). Наиболее правильный тип. Если само приложение графическое, то и настройщик логично делать графический. В большинстве графических приложений есть пункт «настройка», но существуют и настройщики в виде отдельных программ.
• Не столь однозначный вариант, когда программы настройки того же KDE имеют средства для настройки системы. Пример: является ли системной настройка частоты обновления и разрешения экрана? Казалось бы, нет,но с другой стороны этот параметр точно в ведении/*в ведомости у администраторов зарплата обычно*/ администратора сиситемы, так как необходима правка конфигурационного файла графической подсистемы.. В том же KDE Control Center или Gnome можно увидеть ряд подобных утилит, что есть следствие парадигмы «системы в рамках рабочего стола». Идея в следующем: разработчики, которые делают рабочий стол, считают, что разрешение — характеристика рабочего стола, поэтому должны быть инструменты для настройки, если же нет, то нет. Поэтому не обязательно, что эти инструменты из графической подсистемы обязаны заработать.
• Настройка системы в масштабе дистрибутива. Если создатели дистрибутива решили облегчить жизнь пользователю, то создаётся конфигуратор который объявляется системным (alterator в AltLinux, Yast в SuSE). Имеет смысл обратить внимание на этот конфигуратор, поскольку его точно тестируют. Правда, обычно в этих конфигураторах не так много всего и есть. Но это связано со спецификой дистрибутива.
• Настройка некоторых специальных служб, которые имеют собственный графический/веб интерфейс. Есть как минимум две таких службы — CUPS и Samba. Почему эти конфигураторы выделяются отдельно — конфигуратор к таким мощным системам разработчик дистрибутива просто не будет создавать и поддерживать.
• Существуют специальные standalone настроечные среды (наиболее характерным примером является webmin), которые тоже предназначены для того же самого — настройки системы. Есть мнение, что необходимость в таких конфигураторах отпадает. Проблема в том, что разрабатывать и поддерживать подобные конфигураторы очень сложно, вплоть до того, что выясняется, что чем универсальнее тот инструмент, который управляет всем и вся, тем меньшим количеством настроек он управляет. То есть, подобные конфигураторы становятся специфическими либо для дистрибутива, либо для задачи.
• Существует ещё ряд вещей, например, web-движки, которые опять же настраиваются через web-интерфейс.

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

Где искать ответы на вопросы

• Лекция про информационный поиск