Gentoo linux установка пакетов

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

Gentoo — особенный дистрибутив Linux, и выделяется он именно установкой программного обеспечения. Здесь реализована собственная система управления пакетами — portage, которая в отличие от других систем, таких как deb или rpm, предоставляет не полностью собранные, настроенные и готовые для установки пакеты, а только файлы со скриптами компиляции, установки, и последующей настройки.

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

Немного о Portage

Система portage очень похожа на систему портов FreeBSD, а еще чем-то напоминает работу pacman’а в ArchLinux. Как я сказал, здесь нет собранных пакетов, есть только исходники, патчи и файлы, описывающие что с этим всем делать. Такие файлы имеют расширение *.ebuild. По сути, база данных пакетов это система подкаталогов в /usr/protage. При обновлении базы данных просто скачиваться ее новая версия с серверов Gentoo, а старая, используемая в системе удаляется.

Список всех установленных вами пакетов хранится в файле /var/lib/portage/world. Здесь будут только те пакеты, которые вы явно устанавливали с помощью менеджера пакетов. Очень удобная вещь, можно всегда определить что в системе лишнее.

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

Это было немного матчасти, теперь перейдем непосредственно к теме статьи — установка пакетов в Gentoo.

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

Для управления пакетами в Gentoo используется собственный менеджер пакетов — emerge. Чтобы установить пакет Gentoo достаточно набрать:

emerge имя_пакета имя_пакета2

Но это самый простой вариант, emerge поддерживает множество параметров, рассмотрим только те, которые касаются установки пакетов:

• -a — Спрашивать перед установкой;
• -v — Показать более подробную информацию;
• -p — Не устанавливать пакет, только показать информацию;
• -b — Только скомпилировать пакет без установки;
• -O — Установить пакет, не учитывая зависимости;
• -o — установить только зависимости пакета;
• -l —oneshot — Установить пакет, но не добавлять его в файл world;

Например, самой популярной командой, с помощью которой выполняется установка пакетов в Gentoo есть:

sudo emerge -av имя_пакета

Программа выведет всю доступную информацию о пакете, USE флаги, полное имя, размер, категорию и т д. А затем спросит нужно ли его устанавливать:

Здесь красным цветом отмечены активные USE флаги, синим неактивные, салатовым — те, которые будут активированы, например, при переустановке или обновлении.

Буква возле слова ebuild значит действие с пакетом:

• N — будет установлен;
• S — установка в новый слот;
• U — обновление версии пакета;
• D — установка более старой версии пакета;
• R — переустановка;
• F — необходима ручная загрузка исходников пакета;
• f — то же самое, только файлы уже загружены;
• B — пакет конфликтует с другими пакетами, но конфликт будет решен автоматически;
• b — пакет конфликтует с другими пакетами, конфликт нужно решать вручную.

Дальше мы видим количество обрабатываемых пакетов и количество данных которые необходимо скачать в килобайтах.

Если установка программ в Gentoo не нужна, а нужно только посмотреть информацию о пакете можно использовать опцию -p:

sudo emerge -pv имя_пакета

Для ручного обновления системных библиотек лучше использовать опцию -l, чтобы не засорять файл world лишними записями:

sudo emerge -avl имя_пакета

Если к пакету необходимо применить дополнительные USE флаги можно указать их прямо в команде с помощью локальной переменной:

USE=»флаг1 флаг2″ sudo emerge имя_пакета

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

Иногда необходимо установить в 64х битной системе 32 битную программу или библиотеку. Например, Skype и Wine, тянут в зависимостях 32-битные библиотеки, а некоторые программы и вовсе существуют только в 32 битных версиях. Для установки 32-битных пакетов в Gentoo с недавних времен используется USE флаг — abi_x86_32. Достаточно добавить строчку в /etc/portage/package.use, и установить пакет Gentoo:

Еще такой случай, нужно установить только определенную версию пакета и не обновлять его, даже когда появиться новая. Тогда скрываем все версии выше нужной с помощью /etc/portage/package.mask, например, все версии выше 14.0.3:

sudo nano /etc/portage/package.mask

А затем устанавливаем пакет:

sudo emerge — av имя_пакета

Решение проблем с установкой пакетов в Gentoo

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

Источник

Gentoo Linux x86 Handbook: Работа с Gentoo

Contents

Добро пожаловать в Portage

Система Portage — вероятно, самое известное нововведение Gentoo в управлении программным обеспечением. Благодаря высокой гибкости и чрезвычайно богатым возможностям, она зачастую считается лучшим средством управления программным обеспечением из существующих в Linux.

Portage полностью написан на Python и Bash и, следовательно, полностью прозрачен для пользователей, поскольку это скриптовые языки.

Большинство пользователей взаимодействует с Portage с помощью команды emerge . Эта глава не будет дублировать информацию, доступную в emerge man странице. Для полного обзора опций emerge, пожалуйста, обратитесь к странице man:

Gentoo репозиторий

Ebuilds

Когда в документации Gentoo говорится о пакетах имеется ввиду программы, которые доступны Gentoo пользователям в Gentoo репозитории. Репозиторий это коллекция ebuild (сборочных файлов) — файлы содержащие всю информацию, которая нужна Portage для управления программным обеспечением (установка, поиск, запросы и так далее). По умолчанию файлы ebuild находятся в /var/db/repos/gentoo .

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

Обновление Gentoo репозитория

Gentoo репозиторий обычно обновляется с помощью rsync , средства быстрой разностной передачи файлов. Обновление выполняется довольно просто, так как в emerge имеется интерфейс для rsync :

Иногда правила файрвола ограничивают rsync в доступе к зеркалу. В этом случае обновите Gentoo репозиторий с помощью ежедневно генерируемых Gentoo снимков. Утилита emerge-webrsync автоматически загрузит и установит последний снимок в систему:

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

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

Поиск программного обеспечения

Есть несколько способов поиска программ в Gentoo репозитории. Один из способов использовать emerge . По умолчанию emerge —search находит имена пакетов, которые совпадают (полностью или частично) с заданным условием поиска.

Например, чтобы найти все пакеты, содержащие «pdf» в названии:

Для поиска пакетов еще и по тексту описания используйте опцию —searchdesc (или -S ):

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

Установка программы

Когда программное обеспечение было найдено, его легко можно установить командой emerge . Например, для установки gnumeric:

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

Во время установки пакета, Portage скачает необходимый исходный код из интернета (если необходимо) и по умолчанию сохранит его в /var/cache/distfiles/ . После этого он распакует, скомпилирует и установить пакет. Для того чтобы Portage только загрузил исходный код без его установки, добавьте опцию —fetchonly к команде emerge:

Поиск документации для установленных пакетов

Многие пакеты поставляются с собственной документацией. Иногда, USE-флаг doc определяет будет ли установлена документация из пакета или нет. Чтобы увидеть есть ли USE-флаг doc в пакете используйте emerge -vp category/package :

Лучший способ настроить doc USE-флаг это настроить его для каждого пакета с помощью /etc/portage/package.use , так документация будет устанавливаться только для требуемых пакетов. Для большего количества информации, прочитайте раздел USE-флаги.

После установки пакета, его документацию, как правило, можно найти в подкаталоге с именем пакета в каталоге /usr/share/doc/ :

Более точный способ посмотреть список установленных файлов с документаций это воспользоваться equery с параметром —filter . equery используется для запросов к базе данных Portage и поставляется как часть пакета app-portage/gentoolkit:

Параметр —filter можно использовать с другими параметрами, чтобы увидеть место установки множества других типов файлов. Дополнительную информацию можно посмотреть в man-странице equery : man 1 equery .

Удаление программы

Для удаления пакета из системы используйте emerge —unmerge . Она попросит Portage удалить все файлы установленные пакетом из системы. Одним исключением из этого являются файлы конфигурации этого приложения, если они были изменены пользователем. Сохранение конфигурационных файлов позволяет пользователям продолжать работать с пакетом, без необходимости настраивать снова пакет, если он будет установлен снова позже.

Когда удаляется пакет из системы, зависимости от этого пакета, которые установились при установки пакета, все еще остаются в системе. Для того чтобы Portage нашел все зависимости, которые теперь можно удалить, используйте опцию emerge —depclean о которой мы расскажем позже.

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

Чтобы сохранить систему в отличной форме (не говоря уже об установке последних обновлений безопасности) необходимо регулярно обновлять систему. Так как Portage проверяет сборочные файлы только в локальном Gentoo репозитория, поэтому сперва нужно обновить репозиторий. После обновления Gentoo репозитория можно обновить систему с помощью emerge —update @world . В следующем примере также используется опция —ask , которая попросит Portage вывести список пакетов, которые нужно обновить, и запросит подтверждение:

Portage будет искать более новые версии для установленных приложений. Однако, будут проверятся только явно установленные (приложения, перечисленные в /var/lib/portage/world ), но не будут тщательно проверятся их зависимости. Чтобы обновить зависимости этих пакетов тоже, добавьте опцию —deep :

Но все еще это не означает все пакеты: некоторые пакеты в системе необходимы для компиляции и во время создания пакетов, но как только пакет установлен, эти зависимости больше не требуется. Portage называет это «build зависимостями». Чтобы обновить и эти пакеты тоже добавьте опцию —with-bdeps=y :

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

Когда настройки USE в системе были изменены, то рекомендуется также добавить —newuse . В этом случаи Portage проверит требуется ли после этих изменений установить новые пакеты или перекомпилировать существующие:

Метапакеты

У некоторых пакетов в Gentoo репозитории нет содержимого, но они используются для установки набора других пакетов. Например, kde-plasma/plasma-meta установит KDE Plasma desktop в систему, устанавливая в качестве зависимостей различные пакеты, которые нужны Plasma.

Удаление такого пакета из системы, запуская emerge —unmerge пакет, не принесет должного эффекта, так как его зависимости останутся в системе.

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

Все это можно сделать следующими тремя командами:

Лицензии

Начиная с версии Portage 2.1.7 можно принять или отклонить установку программного обеспечения основываясь на лицензии. Все пакеты в дереве содержат запись LICENSE в ebuild. Запуск emerge —search package/category покажет лицензию пакета.

Переменная, которая контролирует допустимые лицензии называется ACCEPT_LICENSE . Ее можно настроить в файле /etc/portage/make.conf . В следующем примере показано значение по умолчанию:

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

Можно настроить ACCEPT_LICENSE глобально в файле /etc/portage/make.conf или специально для отдельного пакета в файле /etc/portage/package.license .

Например, чтобы разрешить google-chrome лицензию для пакета www-client/google-chrome добавьте следующее в /etc/portage/package.license :

Это разрешит установку пакета www-client/google-chrome, но не позволит устанавливать пакет www-plugins/chrome-binary-plugins, хотя он имеет туже лицензию.

Группа лицензий в переменной ACCEPT_LICENSE указываются с символом @ перед ней. Возможной настройкой (которая является значением по умолчанию в Gentoo) является разрешение всех лицензий, кроме Соглашений с лицензией конечного пользователя (EULA), которые обычно требуют прочтения и подписания соглашения о принятии условий лицензии. Это можно достичь, приняв все лицензии (через * ), после чего удалив лицензии из группы EULA, как указано ниже:

Обратите внимание что такая настройка разрешит несвободное программное обеспечение и документацию.

Когда Portage на что-то ругается

Терминология

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

С помощью Portage разные версии отдельного пакета могут сосуществовать в одной системе. В то время, как другие системы управления стремятся называть пакеты в соответствии с версией (например freetype и freetype2), Portage использует технологию под названием SLOT. Ebuild присваивает определенный SLOT для одной версии пакета. Ebuild с разными SLOT способны сосуществовать в одной системе. Например, пакет freetype имеет разные ebuild для SLOT=»1″ и SLOT=»2″.

Есть также пакеты, которые обеспечивают ту же функциональность, но реализуются по-разному. Например, metalogd, sysklogd и syslog-ng это все системные службы журналирования. Приложения, которым нужен «системный журнал», не могут зависеть только от metalogd, так как остальные программы журналирования могут быть равнозначны. В Portage предусмотрены виртуальные пакеты: каждая служба журналирования описана в нем как «эксклюзивная» зависимость от службы журналирования в виртуальном пакете журналирования виртуальной категории, поэтому остальные приложения могут зависеть от пакета virtual/logger. Если ещё не была установлена служба журналирования, то при установке виртуальный пакет «вытянет» первый из указанных в нём пакет журналирования. Если любой пакет журналирования уже был установлен, то в этом случае виртуальная зависимость считается удовлетворенной.

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

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

Каждая инсталляция Gentoo также придерживается определенного профиля, который содержит, помимо прочей информации, ещё и список пакетов, необходимых для нормальной работоспособности системы.

Заблокированные пакеты

В файлах ebuild есть специальные поля, сообщающие Portage о зависимостях. Есть две возможные зависимости: сборочные зависимости, объявленные в переменной DEPEND и зависимости выполнения, объявленные в RDEPEND . Когда одна из этих зависимостей явно указывает на несовместимый обычный или виртуальный пакет, это вызывает блокировку.

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

Чтобы исправить блокировку, пользователи могут либо не устанавливать пакет, либо удалить конфликтующий пакет. В данном примере, можно отказаться от установки postfix или сперва удалить ssmtp.

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

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

Замаскированные пакеты

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

arch keyword Приложение не достаточно протестировано, чтобы его можно было поместить в стабильную ветвь. Подождите несколько дней или недель и попробуйте снова. -arch keyword или -* keyword Приложение не работает на вашей архитектуре. Если вы считаете, что оно должно работать, сообщите об ошибке на нашем сайте Bugzilla. missing keyword Приложение не было протестировано на вашей архитектуре. Попросите группу портирования для вашей архитектуры проверить пакет, или протестируйте его за них и представьте результат на нашем сайте Bugzilla. package.mask В пакете было обнаружена ошибка, нестабильность или еще хуже, и поэтому он был намеренно отмечен как пакет не-для-использования. profile Пакет не подходит для текущего профиля. Приложение может сломать систему при установке или просто несовместимо с профилем на данный момент. license Лицензия пакета не совместима со значением из ACCEPT_LICENSE . Разрешите эту лицензию или необходимую лицензионную группу, настроив их в /etc/portage/make.conf или /etc/portage/package.license .

Необходимо изменить USE-флаг

Сообщение об ошибке может отображаться и так, если —autounmask не установлен:

Такое предупреждение или ошибка происходят, когда пакет, который требуется установить, зависит не только от другого пакета, но также требует, чтобы этот пакет был скомпилирован с особым USE-флагом (или набором USE-флагов). В данном примере, пакет app-text/feelings должен быть скомпилирован с USE=»test», но этот USE-флаг не задан в системе.

Чтобы исправить это, добавьте нужный USE-флаг к глобальным USE-флагам в файле /etc/portage/make.conf или добавьте его для отдельного пакета в файле /etc/portage/package.use .

Отсутствующие зависимости

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

Неоднозначное имя ebuild

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

Циклические зависимости

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

Ошибка загрузки

Portage не смог загрузить исходный код для данного приложения и попытается продолжить установку других приложений (если это возможно). Эта ошибка может быть из-за неправильно синхронизированного зеркала или, возможно, ebuild указывает на неверное место. Также сервер, где находятся исходные коды, может временно недоступен.

Повторите действие через час, чтобы проверить, повторяется ли еще ошибка.

Защита системного профиля

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

Ошибка проверки контрольных сумм

Это признак того, что что-то не так в репозитории Gentoo — часто, возникает из-за того, что сделана ошибка при изменении пакета в репозитории Gentoo.

Когда проверка контрольных сумм завершается ошибкой, не пытайтесь обновить их пакета лично. Запуск ebuild foo manifest не решит проблему; ситуация может ухудшиться.

Вместо этого, подождите час или два, пока репозиторий обновится. Вполне вероятно, что ошибка была замечена сразу, но может пройти некоторое время, пока исправление дойдёт до зеркал. Проверьте Bugzilla, возможно кто-то сообщил о том, что проблема существует или поспрашивайте на #gentoo ( webchat ) (IRC). Если нет, то создайте ошибку о сломанном ebuild.

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

Что такое USE-флаги

Идея USE-флагов

При установке Gentoo (или любого другого дистрибутива, или даже операционной системы вообще) пользователи делают выбор в зависимости от среды, в которой они работают. Настройка для сервера отличается от настройки для рабочего места. Система для игр отличается от системы для 3D-рендеринга.

Это касается не только того, какие пакеты необходимо устанавливать, но и какие возможности в определённых пакетах должны поддерживаться. Если нет необходимости в OpenGL, то зачем устанавливать OpenGL и обеспечивать его поддержку в других пакетах? Если не планируется использовать KDE, зачем утруждать себя сборкой пакетов с поддержкой KDE, если они могут работать и без неё?

Чтобы помочь в решении, что устанавливать/активировать, а что нет, Gentoo предоставляет пользователю простой способ в описании его окружения. Он даёт пользователю выбор, что ему действительно нужно, а также облегчает работу с Portage для принятия более верных решений.

Определение USE-флага

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

Рассмотрим конкретный пример: ключевое слово kde . Если такого ключевого слова нет в переменной USE , все пакеты, у которых поддержка KDE является необязательной, будут скомпилированы без поддержки KDE. Все пакеты, у которых зависимость от KDE необязательна, будут установлены без установки библиотек KDE (в качестве зависимости). Если ключевое слово kde определено, тогда эти пакеты будут скомпилированы с поддержкой KDE, а библиотеки KDE будут установлены в виде зависимостей.

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

Использование USE-флагов

Объявление постоянных USE-флагов

Как уже говорилось ранее, все USE-флаги объявляются в переменной USE . Чтобы облегчить для пользователей поиск и выбор USE-флагов, мы устанавливаем переменную USE в некоторое значение по умолчанию. Это значение определяет коллекцию USE-флагов, которые, по нашему мнению, наиболее часто используются пользователями Gentoo. Эти настройки по умолчанию объявлены в файлах make.defaults , являющиеся частью выбранного профиля.

Профиль, на который определена система, читается из символической ссылки /etc/portage/make.profile . Каждый профиль работает поверх других профилей, поэтому конечный результат в итоге будет суммой всех профилей. В основе всех профилей базовый профиль ( /var/db/repos/gentoo/profiles/base ).

Для просмотра действующих на данный момент USE-флагов (всех) используйте emerge —info :

Как видно, эта переменная уже содержит достаточно много ключевых слов. Не меняйте файлы make.defaults , чтобы подстроить переменную USE под свои нужды: изменения в этих файлах будут отменены при следующем обновлении репозитория Gentoo!

Чтобы изменить настройки по умолчанию, добавьте или удалите ключевые слова в переменной USE . Это можно сделать глобально, определяя переменную USE в файле /etc/portage/make.conf . В этой переменной можно добавлять нужные или удалять ненужные USE-флаги. Для удаления необходимо указать перед ключевым словом префикс в виде знака «минус» ( — ).

Например, для отключения поддержки KDE и Qt и включения поддержки LDAP в /etc/portage/make.conf следует указать следующие USE-флаги:

Объявление USE-флагов для отдельных пакетов

Иногда необходимо определить некий USE-флаг для одного или нескольких приложений, но не для всей системы. Для этого отредактируйте /etc/portage/package.use . Как правило, package.use — это один файл, но может быть и каталогом; смотрите совет ниже и man 5 portage для более подробной информации. Следующий пример подразумевает, что package.use — это один файл.

Например, чтобы включить поддержку Blu-ray только в пакете VLC:

Совет
Если package.use существует в виде каталога (а не одного файла), локальные USE-флаги для конкретного пакета могут определены путём простого создания файла в каталоге package.use/ . Подойдёт любое имя файла, однако рекомендуется придерживаться определённой схемы. Одной из таких схем является использование имени пакета в качестве названия файла. Например, локальное указание USE-флага bluray для пакета media-video/vlc может определено следующим образом:

Аналогичным образом можно запретить использование USE-флагов для определённого приложения. Например, чтобы отключить поддержку bzip2 в PHP (но оставить такую поддержку для всех остальных пакетов через определение USE-флага в файле make.conf ):

Объявление временных USE-флагов

Иногда нужно установить USE-флаг на короткое время. Вместо двойного редактирования файла /etc/portage/make.conf (сначала сделать изменение в переменной USE, а потом его отменить), просто определите переменную USE как переменную окружения. Запомните, что эти настройки будут применены только к введённой команде; пересборка или обновление этого приложения (в явном виде или при обновлении системы) отменят изменения, сделанные с помощью временного определения USE-флага.

Следующий пример временно удаляет pulseaudio из переменной USE во время установки SeaMonkey:

Приоритет

Конечно, есть приоритет в том, какие настройки будут преобладать над другими настройками USE. Последовательность для настроек USE, отсортированная по приоритету (сперва меньший приоритет):

1. Настройки USE по умолчанию объявляются в файле make.defaults из выбранного профиля
2. Определённые пользователем настройки USE в файле /etc/portage/make.conf
3. Определённые пользователем настройки USE в файле /etc/portage/package.use
4. Определённые пользователем настройки USE в виде переменной окружения.

Чтобы отобразить финальные настройки, как их видит Portage, выполните emerge —info . Эта команда отобразит список соответствующих переменных (включая переменные USE ) с их текущими значениями, как их видит Portage.

Адаптация всей системы под новые USE-флаги

После изменений USE-флагов система должна быть обновлена, чтобы изменения вступили в силу. Чтобы сделать это, используйте параметр —newuse для emerge :

Далее, запустите очистку зависимостей Portage (depclean), чтобы удалить зависимости, которые были необходимы в «старой» системе, но теперь, с новыми USE-флагами, устарели.

После завершения работы depclean emerge может предложить пересобрать приложения, которые динамически связаны с общими объектами, удалёнными вместе с устаревшими пакетами. Portage сохранит необходимые библиотеки до тех пор, пока не будет выполнено это действие, чтобы не допустить нарушение работы приложений. Portage хранит список необходимых для пересборки пакетов в наборе preserved-rebuild . Чтобы выполнить пересборку пакетов, запустите:

После того, как эта команда будет завершена, систему можно считать настроенной в соответствии с новыми USE-флагами.

USE-флаги, специфичные для пакета

Просмотр доступных USE-флагов

Возьмём для примера seamonkey: какие USE-флаги он поддерживает? Чтобы получить ответ на этот вопрос, воспользуемся emerge с параметрами —pretend и —verbose :

emerge — не единственная утилита, которую можно использовать для этой задачи. Есть специальная утилита для получения информации о пакете под названием equery из пакета app-portage/gentoolkit.

Теперь запустите equery с аргументом uses для получения списка USE-флагов для определённого пакета. Например, для пакета gnumeric:

Удовлетворение условий REQUIRED_USE

Некоторые пакеты требуют или запрещают определённые комбинации USE-флагов для своей корректной работы. Это выражается через совокупность условий, которые помещены в выражении REQUIRED_USE . Такие условия гарантируют, что все функции и зависимости удовлетворены и сборка будет выполнена корректно и правильно. Если какое-либо из условий не выполняется, emerge предупредит вас об этом и попросит исправить эту проблему.

Некоторые примеры для выражений REQUIRED_USE указаны ниже:

Пример	Описание
REQUIRED_USE=»foo? ( bar )»	Если foo установлен, то bar должен быть тоже установлен.
REQUIRED_USE=»foo? ( !bar )»	Если foo установлен, то bar не должен быть установлен.
REQUIRED_USE=»foo? ( || ( bar baz ) )»	Если foo установлен, то bar или baz должен быть установлен.
REQUIRED_USE=»^^ ( foo bar baz )»	Только один из foo , bar или baz должен быть установлен.
REQUIRED_USE=»|| ( foo bar baz )»	Хотя бы один из foo bar или baz должен быть установлен (но можно больше).
REQUIRED_USE=»?? ( foo bar baz )»	Установка необязательна, но только один из foo bar или baz может быть установлен.

Возможности Portage

В Portage есть несколько дополнительных возможностей (features), которые улучшат опыт работы с Gentoo. Многие из этих возможностей полагаются на определённые программы, которые улучшают производительность, надёжность, безопасность и так далее.

Чтобы включить или отключить определённые возможности Portage, отредактируйте /etc/portage/make.conf и измените или установите переменную FEATURES , которая содержит ключевые слова возможностей, разделённые пробелом. В некоторых случаях необходимо установить дополнительные утилиты, на которые опирается эта возможность.

Не все возможности, которые поддерживает Portage, перечислены здесь. Для полного обзора, пожалуйста, обратитесь к man-странице make.conf :

Чтобы найти, что на данный момент установлено в FEATURES , запустите emerge —info и поищите переменную FEATURES или отфильтруйте её с помощью grep :

Распределённая сборка

Использование distcc

distcc — это программа для распределённой сборки по нескольким, не обязательно идентичным, машинам в сети. Клиент distcc посылает всю необходимую информацию на доступные сервера distcc (на которых работает distccd), чтобы те скомпилировали части исходного кода для клиента. В результате получается более быстрая сборка.

Больше информации о distcc (и как он работает с Gentoo) можно найти в статье Distcc.

Установка distcc

Distcc поставляется с графическим монитором для отслеживания заданий, отправляемых компьютером на компиляцию. Данный монитор устанавливается при включённом флаге USE=gnome или USE=gtk .

Включение поддержки distcc в Portage

Добавьте distcc в переменную FEATURES в файле /etc/portage/make.conf . Далее, отредактируйте переменную MAKEOPTS и увеличьте число параллельных задач компиляции настолько, насколько это позволяет система. Рекомендуется использовать -jN , где N это число CPU, на которых будет запускаться distccd (включая локальный компьютер), плюс один. Не забывайте, что это просто рекомендация.

Теперь запустите distcc-config и введите список доступных серверов distcc. В качестве простого примера предположим, что среди доступных серверов distcc 192.168.102 (локальный компьютер), а 192.168.1.103 и 192.168.1.104 (два «удалённых» узла):

Не забудьте также запустить демон distccd:

Кэширование собранных объектов

О ccache

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

Для более подробной информации о ccache, пожалуйста, посетите их домашнюю страницу.

Установка ccache

Для установки ccache запустите следующую команду:

Включение поддержки ccache в Portage

Откройте /etc/portage/make.conf и добавьте ccache к значению, которое определено в переменной FEATURES . Создайте переменную FEATURES , если она не существует. Далее добавьте новую переменную, которая называется CCACHE_SIZE , и установите ее в 2G :

Чтобы проверить функциональность ccache, запросите его статистику. Поскольку Portage использует другой домашний каталог для ccache, необходимо временно установить переменную CCACHE_DIR :

В Portage домашний каталог по умолчанию для ccache — /var/tmp/ccache/ ; но это можно изменить, настроив переменную CCACHE_DIR в файле /etc/portage/make.conf .

Если ccache запущен автономно (без Portage), он будет использовать каталог по умолчанию $/.ccache/ , именно поэтому необходимо указать переменную CCACHE_DIR при запросе (Portage) статистики ccache.

Использование ccache отдельно от Portage

Чтобы использовать ccache для компиляции без Portage, добавьте /usr/lib/ccache/bin/ в начало переменной PATH (до /usr/bin ). Это можно сделать, отредактировав

/.bash_profile в домашнем каталоге пользователя. Использование

/.bash_profile — это только один из способов определения переменных PATH .

/.bash_profile Настройка месторасположения ccache перед другими PATH

Поддержка двоичных пакетов

Создание прекомпилированных пакетов

Portage поддерживает установку двоичных пакетов. Несмотря на то, что Gentoo не предоставляет двоичных пакеты, Portage сам может сделать такие пакеты.

Чтобы создать бинарный пакет, воспользуйтесь командой quickpkg , если пакет уже установлен в системе, или скомпилируйте его с параметром —buildpkg или —buildpkgonly .

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

Более расширенные возможности при создании набора двоичных пакетов можно получить, используя catalyst. Более подробную информацию о catalyst можно прочитать в Catalyst FAQ.

Установка прекомпилированных пакетов

Хотя Gentoo не предоставляет таковые, можно создать централизованный репозиторий двоичных пакетов. Для того, чтобы использовать такой репозиторий, нужно сообщить Portage об этом с помощью переменной PORTAGE_BINHOST , которая указывает на такое хранилище. Например, если бинарные пакеты находятся по адресу ftp://buildhost/gentoo:

Чтобы установить двоичный пакет, добавьте параметры —getbinpkg и —usepkg в команду emerge. Первая сообщает emerge, что нужно загрузить двоичный пакет из уже определённого ранее сервера, а вторая просит emerge попытаться установить двоичный пакет до загрузки исходного кода и его компиляции.

Например, чтобы установить gnumeric из прекомпилированного пакета:

Больше информации о двоичных пакетах в emerge можно найти в man-странице emerge:

Распространение двоичных пакетов для других

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

В ebuild может быть определено ограничение bindist в переменной RESTRICT , если собранные двоичные файлы не подлежат распространению. Иногда такое ограничение обусловлено одним или несколькими USE-флагами.

По умолчанию Portage не маскирует пакеты из-за таких ограничений. Это можно изменить, глобально настроив переменную ACCEPT_RESTRICT в файле /etc/portage/make.conf . Например, чтобы замаскировать пакеты, у которых есть ограничение bindist , добавьте следующую строку в файл make.conf :

Также можно переопределить переменную ACCEPT_RESTRICT , добавив параметр —accept-restrict в команду emerge . Например, —accept-restrict=-bindist временно замаскирует пакеты с ограничением bindist .

Также, в случае распространения пакетов, рекомендуется настроить переменную ACCEPT_LICENSE . Смотрите раздел Лицензии.

Загрузка файлов

Userfetch

Portage обычно запускается от пользователя root. Настройка FEATURES=»userfetch» позволит Portage сбросить привилегии root при загрузке исходного кода и выполнит эту операцию с правами пользователя/группы portage:portage. Это небольшое усиление безопасности.

Если userfetch установлена в FEATURES , убедитесь, что изменили владельца у всех файлов в /var/db/repos/gentoo с помощью команды chown , запущенной с правами root:

Проверка архивов исходных файлов

Чтобы перепроверить целостность и (возможно) повторно скачать ранее удаленные/поврежденные архивы исходных файлов (distfiles) для всех установленных пакетов, выполните:

Уровни запуска

Процесс загрузки системы

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

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

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

И, наконец, когда все сценарии выполнены, init подключает терминалы (чаще всего просто виртуальные консоли, которые видны при нажатии Alt + F1 , Alt + F2 и так далее), прикрепляя к каждой консоли специальный процесс под названием agetty . Этот процесс впоследствии обеспечивает возможность входа в систему через эти терминалы с помощью login.

Сценарии инициализации

Процесс init запускает сценарии из каталога /etc/init.d/ не просто в случайном порядке. Более того, запускаются не все сценарии из /etc/init.d/ , а только те, которые предписано исполнять. Решение о запуске сценария принимается в результате просмотра каталога /etc/runlevels/ .

Во-первых, init запускает все сценарии из /etc/init.d/ , на которые есть символьные ссылки из /etc/runlevels/boot/ . Обычно сценарии запускаются в алфавитном порядке, но в некоторых из них имеется информация о зависимостях от других, указывающая системе на необходимость их предварительного запуска.

Когда все сценарии, указанные в /etc/runlevels/boot/ , будут выполнены, init переходит к запуску сценариев, на которые есть символьные ссылки из /etc/runlevels/default/ . И снова запуск происходит в алфавитном порядке, пока в сценарии не встретится информация о зависимостях; тогда порядок изменяется для обеспечения правильного порядка запуска. Именно по данной причине команды, используемые во время установки Gentoo Linux, используют default , как в команде rc-update add sshd default .

Как работает init

Конечно, init не принимает решений сам по себе. Ему необходим конфигурационный файл, где описаны необходимые действия. Этот файл — /etc/inittab .

Вспомните последовательность загрузки, описанную чуть ранее: первое действие init — это монтирование всех файловых систем. Это определяется в следующей строке файла /etc/inittab :

Этой строкой процессу init предписывается выполнить /sbin/openrc sysinit для инициализации системы. Самой инициализацией занимается сценарий /sbin/openrc , так что можно сказать, что init делает не слишком много — он просто делегирует задачу по инициализации системы другому процессу.

Во-вторых, init выполняет все сценарии, на которые есть символьные ссылки из /etc/runlevels/boot/ . Это определяется следующей строкой:

И снова все необходимые действия выполняются сценарием openrc. Заметьте, что параметр, переданный openrc (boot), совпадает с названием используемого подкаталога в /etc/runlevels/ .

Теперь init проверяет свой конфигурационный файл, чтобы определить, какой уровень запуска нужно запустить. Для этого из /etc/inittab считывается строка:

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

В строке, определяющей уровень 3, для запуска служб снова используется сценарий openrc (на этот раз с аргументом default ). Опять-таки, обратите внимание, что аргумент, передаваемый openrc, совпадает с названием подкаталога из /etc/runlevels/ .

По окончании работы openrc init принимает решение о том, какие виртуальные консоли включить и какие команды выполнить в каждой из них:

Доступные уровни запуска

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

В Gentoo определено семь уровней запуска: три служебных и четыре определяемых пользователем. Служебные называются sysinit, shutdown и reboot. Действия, совершаемые ими, в точности соответствуют их названиям: инициализация системы, выключение системы и её перезагрузка.

Определяемые пользователем уровни — это те, которым соответствуют подкаталоги в /etc/runlevels/ : boot, default, nonetwork и single. Уровень boot запускает все службы, необходимые системе и используемые всеми остальными уровнями. Остальные уровни отличаются друг от друга запускаемыми службами: default используется для повседневной работы, nonetwork — для тех случаев, когда не требуется сеть, а single используется при необходимости восстановления системы.

Работа со сценариями инициализации

Сценарии, запускаемые процессом openrc, называются сценариями инициализации. Каждый сценарий из /etc/init.d/ может запускаться с аргументами start , stop , restart , zap , status , ineed , iuse , iwant , needsme , usesme или wantsme .

Для запуска, остановки или перезапуска службы (и всех, зависящих от неё) следует использовать start , stop и restart :

Если вы хотите остановить службу, но оставить зависимые от неё работающими, можно использовать опцию —nodeps вместе с аргументом stop:

Чтобы узнать текущее состояние службы (запущена, остановлена, и так далее), можно использовать аргумент status :

Если указано, что служба работает, но вы знаете, что это не так, можно сбросить состояние на stopped , используя аргумент zap :

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

Аналогично можно узнать, какие службы нуждаются в данной службе ( needsme ) или могут её использовать ( usesme или wantsme ):

Обновление уровней запуска

rc-update

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

Используя rc-update , можно включать и исключать сценарии инициализации из уровней запуска. Из rc-update автоматически запускается сценарий depscan.sh для перестроения дерева зависимостей.

Добавление и удаление служб

В процессе установки Gentoo вы уже добавляли сценарии инициализации в уровень запуска default. Ранее в данном документе было объяснено, что означает default. Кроме уровня запуска, сценарию rc-update требуется второй аргумент, определяющий действие: add (добавить), del (удалить) или show (показать).

Для того, чтобы добавить или удалить сценарии инициализации, просто введите rc-update с аргументом add или del , затем название сценария и уровня запуска. Например:

По команде rc-update -v show выводится список всех доступных сценариев инициализации с указанием списка уровней запуска, на которых они будут выполняться:

Вы также можете запустить rc-update show (без -v ) чтобы просто просмотреть включенные сценарии инициализации и их уровни запуска.

Настройка служб

Почему необходима дополнительная настройка

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

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

Каталог conf.d

В Gentoo предусмотрен очень простой способ настройки служб: для каждого сценария, предполагающего настройку, в каталоге /etc/conf.d/ есть конфигурационный файл. Например, у сценария, запускающего apache2 (под названием /etc/init.d/apache2 ) есть конфигурационный файл /etc/conf.d/apache2 , где хранятся параметры, передаваемые серверу Apache 2 при запуске:

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

Написание сценариев инициализации

Это необходимо?

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

Не используйте сценарий инициализации, идущий со службой, если он не написан специально для Gentoo: сценарии Gentoo не совместимы со сценариями, используемыми в других дистрибутивах! То есть, если другой дистрибутив не использует OpenRC!

Структура

Основная структура сценария инициализации показана ниже.

В любом сценарии инициализации должна быть определена функция start() или переменная command . Все остальные разделы необязательны.

Зависимости

Существуют три настройки, работающие с зависимостями, которые можно определить, и они будут влиять на порядок запуска сценария инициализации: want , use и need . Кроме этих, существуют еще два влияющих на порядок загрузки метода, называющихся before и after . Последние два не определяют зависимости, они не остановят с ошибкой основной сценарий, если выбранный не должен запускаться (или не смог запуститься).

• Настройка use информирует систему init, что данный скрипт использует функциональность некоторого сценария, но строго от него не зависит. Хорошим примером будет use logger или use dns . Если эти службы есть, они будут использоваться, но если у вас нет системы журналирования или DNS-сервера, службы все равно будут работать. Если службы существуют, они будут запущены до того, как запустится сценарий, использующий их.
• Настройка want похожа на use с одним исключением. use учитывает только те службы, которые были добавлены в какой-либо уровень запуска. want попытается запустить любую доступную службу, даже если она не была добавлена в один из уровней запуска.
• Настройка need ­— это жёсткая зависимость. Она означает, что сценарий, которому нужен другой, не запустится, пока другой сценарий не запустится успешно. Также, если другой сценарий будет перезапущен, то этот тоже будет перезапущен.
• При использовании before , данный сценарий запускается до некоторого сценария, если выбранный сценарий — часть того же уровня инициализации. Так, сценарий инициализации xdm, который определен before alsasound будет запущен до сценария alsasound, но только если alsasound запланирован запуститься на том же уровне инициализации. Если alsasound не запланирован для запуска, то эта конкретная настройка не будет иметь эффекта, и xdm запустится в тот момент времени, который система init посчитает лучшим вариантом.
• Похожим образом after информирует систему init, что данный сценарий нужно запустить после некоторого сценария, если выбранный сценарий является частью того же уровня инициализации. Если нет, то настройка не имеет эффекта, и сценарий будет запущен системой init в момент времени, который, как она посчитает, будет наилучшим.

Из изложенного должно быть ясно, что need — это единственная действительная настройка зависимостей, так как она влияет на то, будет ли запущен сценарий или нет. Все остальные являются больше указателями системе init, говорящими в каком порядке сценарии могут (или должны) запускаться.

Теперь, если вы взглянете на существующие сценарии инициализации Gentoo, вы заметите, что некоторые из них имеют зависимости от вещей, которые не являются сценариями. Эти вещи мы называем виртуальными.

Виртуальная зависимость — это зависимость от функций, предоставляемых службой, но не какой-то единственной службой. Сценарий инициализации может зависеть от службы журналирования, но таких достаточно много (metalogd, syslog-ng, sysklogd и тому подобное). Поскольку нельзя нуждаться в каждой из них (ни в одной нормальной системе они не запущены все сразу), мы обеспечили предоставление виртуальной зависимости всеми этими службами.

Например, давайте взглянем на информацию о зависимостях postfix.

Как можно увидеть, служба postfix:

• требует (виртуальную) зависимость в сети (net, которая предоставляется, например, /etc/init.d/net.eth0 )
• использует (виртуальную) зависимость logger (которая предоставляется, например, /etc/init.d/syslog-ng )
• использует (виртуальную) зависимость dns (которая, предоставляется, например, /etc/init.d/named )
• предоставляет (виртуальную) зависимость mta (общая для всех почтовых серверов).

Порядок запуска

Как было описано в предыдущем разделе, можно сказать системе init, в каком порядке она должна запускать (или останавливать) сценарии. Этот порядок поддерживается как через настройки зависимостей use и need, так и через настройки порядка before и after. Так как мы описали их ранее, давайте посмотрим на службу Portmap, как на пример такого сценария инициализации.

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

Если службе необходима возможность записывать данные на локальные диски, она должна потребовать localmount. Если она что-либо поместит в /var/run/ , например, PID-файл, она должна запускаться после bootmisc:

Стандартные функции

Следом за разделом depend() потребуется определить функцию start() . В ней содержатся все команды, необходимые для запуска службы. Рекомендуется применять функции ebegin и eend для сообщений пользователю о том, что происходит:

Как —exec , так и —pidfile должны использоваться в функциях start и stop. Если служба не создает PID-файл, то по возможности используйте —make-pidfile , хотя это может потребовать дополнительного тестирования. В ином случае не используйте PID-файлы. Можно добавить —quiet к аргументам start-stop-daemon, но это не рекомендуется, если только служба не очень многословная. Использование —quiet может скрыть отладочную информацию, если служба не может запуститься.

Другой интересной настройкой, используемой в вышеприведенном примере является проверка содержимого переменной RC_CMD . В отличие от предыдущей системы инициализации, новая система OpenRC не поддерживает отдельную функциональность restart для каждого скрипта. Вместо этого сценарий должен проверить содержимое переменной RC_CMD , чтобы проверить, вызывается ли функция (как start() , так и stop() ) как часть restart, или нет.

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

Еще одной функцией, которую можно определить (но не обязательно это делать), является stop() . Система init, применяемая нами, достаточно развита и в состоянии самостоятельно заполнить эту функцию, если используется start-stop-daemon.

Если служба запускает некоторый другой сценарий (например, на Bash, Python или Perl), и этот сценарий позднее изменяет имя (например, с foo.py на foo), тогда нужно добавить —name к start-stop-daemon. Нужно определить имя, на которое сценарий изменит свое имя. В приведенном примере, служба запускает foo.py , а потом это имя меняется на foo:

У start-stop-daemon есть отличная man-страница, которую можно посмотреть, если нужна дополнительная информация.

Синтаксис сценариев инициализации, применяемых в Gentoo, основан на оболочке POSIX, поэтому можно свободно использовать внутри своих скриптов sh-совместимые конструкции. Остальные конструкции, вроде тех, которые специфичны только для bash, следует выносить за пределы сценария, чтобы быть уверенным, что сценарий будет работать независимо от того, что Gentoo может сделать со своей системой init.

Добавление дополнительных параметров

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

• extra_commands — команду можно запустить при любом состоянии службы
• extra_started_commands — команду можно запустить, когда служба запущена
• extra_stopped_commands — команду можно запустить, когда служба остановлена

Переменные для настройки служб

Для поддержки файлов конфигурации из каталога /etc/conf.d/ ничего дополнительно делать не нужно: при запуске сценария инициализации автоматически подключаются следующие файлы (то есть переменные из них становятся доступны):

• /etc/conf.d/YOUR_INIT_SCRIPT
• /etc/conf.d/basic
• /etc/rc.conf

Кроме того, если сценарий инициализации предоставляет виртуальную зависимость (например, net), то также подключается файл, соответствующий этой зависимости (например, /etc/conf.d/net ).

Изменение поведения уровней запуска

Кому это может быть полезным

Большинству пользователей ноутбуков знакома ситуация: дома нужен запуск net.eth0, и наоборот, в дороге запуск net.eth0 не нужен (так как сеть недоступна). В Gentoo можно изменять поведение уровней запуска по своему усмотрению.

Например можно создать второй загружаемый уровень запуска default, в котором будут другие сценарии. Затем, при загрузке, можно выбрать, какой из уровней default следует использовать.

Использование программного уровня (softlevel)

Прежде всего, создайте каталог для второго уровня запуска default. Например, создадим уровень запуска offline:

Добавьте необходимые сценарии в только что созданный уровень запуска. Например, чтобы получить точную копию уровня default, за исключением net.eth0:

Даже несмотря на то, что net.eth0 был удален с уровня запуска offline, udev может попытаться запустить любые устройства, которые найдёт, и запустить соответствующие службы. Данная функциональность называется hotplugging. По умолчанию, Gentoo отключает hotplugging.

Чтобы включить hotplugging, но только для конкретного набора сценариев, используйте переменную rc_hotplug в /etc/rc.conf :

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

Использование загрузочного уровня (bootlevel)

Использование загрузочного уровня полностью аналогично использованию программного уровня. Единственная разница состоит в том, что определяется второй уровень boot вместо второго уровня default.

Переменные окружения

Введение

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

Наиболее важные переменные

В следующей таблице перечислен ряд переменных, используемых в системе Linux и описание их использования. Примеры их значений приведены после таблицы.

Variable	Description
PATH	Эта переменная содержит разделенный двоеточиями список каталогов, в которых система ищет исполняемые файлы. Если введенное имя это исполняемый файл (например, ls , rc-update или emerge ), но если исполняемый файл не находится в каталоге из списка, то система не будет выполнять его (одна можно указать полный введен в качестве команды, такую как /bin/ls ).
ROOTPATH	У этой переменной те же функцию, что и у PATH , но в ней содержатся только те каталоги, которые должны быть проверены, когда root-пользователь вводит команду.
LDPATH	Эта переменная содержит разделенный двоеточиями список каталогов, в которых динамический линковщик ищет библиотеки.
MANPATH	Эта переменная содержит разделенный двоеточиями список каталогов, в которых команда man ищет страницы man.
INFODIR	Эта переменная содержит разделенный двоеточиями список каталогов, в которых команда info выполняет поиск страниц info.
PAGER	Эта переменная содержит путь к программе, используемой для отображения содержимого файлов (таких как less или more ).
EDITOR	Эта переменная содержит путь к программе, используемой для изменения содержимого файлов (таких как nano или vi ).
KDEDIRS	Эта переменная содержит разделенный двоеточиями список каталогов, содержащих специфический материал для KDE.
CONFIG_PROTECT	Эта переменная содержит разделенный пробелами список каталогов, которые должны быть защищены Portage при обновлении.
CONFIG_PROTECT_MASK	Эта переменная содержит разделенный пробелами список каталогов, которые не должны быть защищены Portage при обновлении.

Ниже приведен пример, содержащий все эти переменные:

Определение переменных глобально

Каталог env.d

Для централизации определения переменных в Gentoo используется каталог /etc/env.d/ . Внутри каталога есть несколько файлов, такие как 00basic , 05gcc и так далее, которые содержат переменные, необходимые программе из названия файла.

Например, когда установлен gcc , ebuild создает файл с названием 05gcc , который содержит определения следующих переменных:

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

Например, когда обновляется gcc , также обновляется и файл /etc/env.d/05gcc без малейшего участия пользователя.

От этого выигрывает как Portage, так и пользователь. Иногда пользователям необходимо установит определенную переменную окружения для всей системы. Например, возьмем переменную http_proxy . Чтобы не возиться с /etc/profile , пользователь может просто создать файл (скажем /etc/env.d/99local ) и написать необходимое определения в нём:

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

env-update

Несколько файлов в /etc/env.d/ определяют переменную PATH . Это не ошибка: когда выполняется команда env-update , она добавит другие определения перед обновлением переменного окружения, что позволяет просто добавлять для пакетов (или пользователей) свои собственные настройки переменного окружения без вмешательство в уже существующие значениями.

Сценарий env-update добавляет значения из файлов /etc/env.d/ в алфавитном порядке. Имена файлов должны начинаться с двух десятичных чисел.

Объединение переменных происходит не всегда, а только для следующих переменных: ADA_INCLUDE_PATH , ADA_OBJECTS_PATH , CLASSPATH , KDEDIRS , PATH , LDPATH , MANPATH , INFODIR , INFOPATH , ROOTPATH , CONFIG_PROTECT , CONFIG_PROTECT_MASK , PRELINK_PATH , PRELINK_PATH_MASK , PKG_CONFIG_PATH и PYTHONPATH . Для всех остальных переменных используется последнее значение (в алфавитном порядке файлов в /etc/env.d/ ).

Можно добавить больше переменных к списку объединяемых переменных, добавив имя переменной в одну из переменных COLON_SEPARATED или SPACE_SEPARATED (также внутри файла /etc/env.d/ ).

При запуске env-update , сценарий создаст все переменные окружения и поместит их в /etc/profile.env (который используется /etc/profile ). Кроме того, сценарий на основе значения LDPATH создаст /etc/ld.so.conf . После этого он запустит ldconfig , чтобы пересоздать файл /etc/ld.so.cache , используемый динамическим компоновщиком.

Чтобы увидеть эффект работы env-update сразу после его запуска, выполните следующую команду, чтобы обновить окружение. Пользователи, которые устанавливали Gentoo сами, вероятно, вспомнят эту команду из инструкции по установке:

Определение переменных локально

Для пользователя

Не всегда нужно определять переменную окружения на глобальном уровне. Например, кому-то может понадобится добавить /home/my_user/bin и текущий рабочий каталог (каталог в котором находится пользователь) в переменную PATH , но не нужно чтобы все другие пользователи получили такой же PATH . Для определения переменной окружения локально, используйте

/.bashrc Дополнительный PATH для локального использования

Переменная PATH будет обновлена после выхода/входа.

Для сессии

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

/.bashrc на короткий срок.

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

Warning: Display title «Gentoo Linux x86 Handbook: Работа с Gentoo» overrides earlier display title «Handbook:X86/Full/Working».

Источник