Abstract
Здесь собрана информация по нюансам использования portage из самых разных источников: документации, web-сайтов, Gentoo-шных форумов, maillist-ов и личного опыта. В некоторых местах (особенно где английский текст) — это просто cope&paste из этих источников.
Предполагается, что базовые знания по portage уже есть, и рассказывать что
такое emerge --sync
или USE-флаги не нужно.
Основной упор при сборе информации делался на:
-
описание возможностей portage
-
описание разницы между разными способами выполнить одну и ту-же задачу (с примерами/аргументами описывающими последствия выполнения задачи "неправильным" способом)
-
составление "рецептов" по решению типовых задач
-
полноту описания (правда, portage это движущаяся цель - постоянно вносятся изменения и добавляются новые возможности - так что этот документ непрерывно устаревает)
Всё что касается RC-скриптов (/etc/init.d/, /etc/conf.d/) я не изучал вообще т.к. я ими не пользуюсь. Мой способ загрузки системы описан на хабре в статье Как загружается Linux а сами скрипты выложены здесь. |
Устаревшая версия этого документа выложена на: http://gentoo.ru/node/193, плюс самый полезный :) раздел этого документа выложен в вики: http://ru.gentoo-wiki.com/HOWTO_Полное_обновление_системы. |
Настройка portage
Текущие настройки выдаёт emerge --info
. Они являются результатом
объединения глобальных и пользовательских настроек.
- /etc/make.profile
-
Симлинк указывающий на текущий профайл.
- /etc/make.conf
-
Пользовательские настройки по умолчанию.
- /etc/portage/
-
Пользовательские настройки для отдельных пакетов и профайла.
- переменные окружения
-
Например:
USE=-flag ACCEPT_KEYWORDS=~x86 emerge something
.
Использовать переменные окружения не рекомендуется т.к. эти изменения не будут учтены при следующих перекомпиляциях пакетов. |
- /etc/make.globals
-
Глобальные настройки.
- /usr/portage/
-
Файлы с разными настроками, в т.ч. package.mask.
- /usr/portage/ВАШ/ТЕКУЩИЙ/ПРОФАЙЛ/
-
Плюс все профайл-каталоги которые этот профайл наследует (имя унаследованного профайла-каталога находится в файле parent, а сам каталог с профайлом определяется через симлинк /etc/make.profile — см. выше).
Файлы с глобальными настройками редактировать нельзя, т.к.
изменения будут потеряны при следующем emerge --sync . |
-
make.conf(5)
-
portage(5)
-
/etc/make.conf.example
Управление установкой пакетов
Настройка компиляции
Для оптимизации компилируемых пакетов можно настроить
$CHOST
, $CFLAGS
, $CXXFLAGS
.
- CHOST
-
Значение
$CHOST
в /etc/make.conf обычно требуется менять только при установке из stage1, до запуска bootstrap. Из Gentoo Handbook инструкции по установке из stage1 некоторое время назад убрали, поэтому либо выбирайте при установке stage3 соответствующий вашей архитектуре и не трогайте CHOST, либо устанавливайте из stage1.Если вам нужно изменить
$CHOST
на работающей системе (например перейти с i386 на i686, что необходимо при обновлении glibc до 2.4), то внимательно изучите Changing the CHOST variable и даже не пытайтесь ограничиться простым редактированием значения$CHOST
в /etc/make.conf - угробите систему! - CFLAGS, CXXFLAGS
-
Как настраивать можно почитать в Compilation Optimization Guide. Если вы используете Hardened Gentoo или для вас критична надёжность работы а не максимальная производительность, то рекомендуется использовать исключительно Safe CFLAGS.
Для ускорения компиляции на многопроцессорных/многоядерных машинах нужно
установить $MAKEOPTS
в /etc/make.conf.
MAKEOPTS="-j3" # где 3 это кол-во процессоров/ядер плюс один
Выбор версии пакета
Одновременно в portage может быть доступно несколько разных версий одного пакета, и вы можете выбрать какую версию устанавливать.
Способов указать нужную версию довольно много (см. “Atom” в ebuild(5)). Если вы не укажете конкретную версию, то будет автоматически выбрана одна из версий соответствующая вашему условию.
- cate-gory/package
-
Последняя доступная версия.
- cate-gory/package:SLOT
-
Последняя доступная версия в этом SLOT.
- =cate-gory/package-version
-
Конкретно эта версия.
- >cate-gory/package-version
-
Любая версия новее этой.
- ⇐cate-gory/package-version
-
Любая версий не новее этой.
Кстати, осторожнее с указанием версий со знаками < > в командной строке — не забывайте брать такие версии в кавычки. |
Версия по умолчанию (стабильная/тестируемая)
Каждая версия помечена стабильный/тестируемый/не работает отдельно для каждой архитектуры поддерживаемой Gentoo.
- arch
-
Стабильный. Например:
x86
. - ~arch
-
Тестируемый. Например:
~x86
. - -arch
-
Не работает. Например:
-x86
.
С помощью $ACCEPT_KEYWORDS
вы можете указать, какие версии ставить по
умолчанию — стабильные или тестируемые. По умолчанию ставятся
стабильные: ACCEPT_KEYWORDS="x86"
(для архитектуры x86). Если вы
хотите помочь разработчикам Gentoo в тестировании или любите самый свежий
софт — установите ACCEPT_KEYWORDS="~x86"
.
Так же это можно настроить индивидуально для нужных пакетов в /etc/portage/package.keywords.
- cate-gory/package
-
Разрешает использовать тестируемые версии пакета.
- cate-gory/package -~x86
-
Запрещает использовать тестируемые версии пакета (имеет смысл при
ACCEPT_KEYWORDS="~x86"
). - =cate-gory/package-version
-
Разрешает использовать конкретно эту тестируемую версию пакета: не будет пытаться откатить её на предыдущую стабильную при
emerge -u
, и не будет автоматически обновлять её на более новые тестируемые версии. - ~cate-gory/package-version
-
Где -version не включает номер ревизии (-rX), будет работать как предыдущий вариант с одним исключением — автоматические обновления на более новые тестируемые ревизии этой-же версии пакета будут разрешены.
Типичная конфигурация: в $ACCEPT_KEYWORDS по умолчанию разрешены
только стабильные версии, а в /etc/portage/package.keywords
разрешены тестируемые версии для некоторых пакетов. |
Если вы не указываете конкретную версию пакета при установке, то будет
установлена либо последняя стабильная версия либо самая последняя версия
(в зависимости от значений $ACCEPT_KEYWORDS
и
/etc/portage/package.keywords).
Замаскированные версии
Некоторые версии пакета могут быть замаскированы. Для установки замаскированных версий их нужно предварительно демаскировать.
-
Тестируемые/нерабочие пакеты по умолчанию замаскированы.
Демаскируются через
$ACCEPT_KEYWORDS
либо /etc/portage/package.keywords (см. Версия по умолчанию (стабильная/тестируемая)). -
Hardmasked пакеты прописаны в файлах
- /usr/portage/profiles/package.mask
-
для всех профайлов
- /etc/make.profile/packages
-
для текущего профайла
- /etc/portage/package.mask
-
пользовательские
Для демаскировки их нужно прописать в /etc/portage/package.unmask (или просто удалить из /etc/portage/package.mask).
Одновременная установка нескольких версий (SLOT)
Некоторые пакеты допускают одновременную установку нескольких версий,
например у вас могут быть установлен dev-java/sun-jdk версий 1.6.0.05,
1.5.0.15 и 1.4.2.17. Обычно в этом случае вы можете выбирать какая из
этих версий будет использоваться по умолчанию с помощью eselect
или
java-config
, gcc-config
, etc.
Выбор опциональных возможностей пакета (USE-флаги)
При установке пакета вы можете указать нужные вам опциональные возможности этого пакета через USE-флаги.
Возможности, поддержку которых нужно включить (или наоборот, отключить)
по умолчанию указываются с помощью $USE
. Индивидуальные USE-флаги для
конкретных пакетов можно указать в /etc/portage/package.use.
USE-флаги могут быть добавляться/удаляться автоматически после установки/удаления соответствующих пакетов: /etc/make.profile/use.defaults.
После изменения USE-флагов рекомендуется пересобрать все пакеты,
на которые влияют эти флаги: emerge -N world
, после чего
сделать emerge -a --depclean
чтобы удалить ставшие лишними из-за
изменения USE-флагов пакеты.
-
Default USE setting declared in /etc/make.profile/make.defaults (плюс make.defaults из унаследованных профайл-каталогов)
-
Inherited USE setting if a package from /etc/make.profile/use.defaults is installed (плюс use.defaults из унаследованных профайл-каталогов)
-
User-defined USE setting in /etc/make.conf
-
User-defined USE setting in /etc/portage/package.use
-
User-defined USE setting as environment variable
- /usr/portage/profiles/use.desc
-
Для USE-флагов означающих одно и то же для всех пакетов.
- /usr/portage/profiles/use.local.desc
-
Для USE-флагов означающих разные возможности для разных пакетов.
Дополнительные/модифицированные пакеты (оверлеи)
Помимо пакетов доступных через официальное дерево portage можно иметь свои локальные наборы пакетов. Это может потребоваться для установки пакетов, которых в официальном portage нет, или для установки модифицированных версий пакетов из официального portage (например если вам нужно наложить свой патч на этот пакет).
Каталог с официальным деревом portage задается в /etc/make.conf как
$PORTDIR
. Каталоги с дополнительными наборами пакетов (оверлеями)
указываются там же как $PORTDIR_OVERLAY
(обычно это один каталог:
/usr/local/portage/).
Если пакет одной и той-же версии будет найден и в основном каталоге, и в оверлеях — будет использоваться версия из оверлея.
Дополнительные или изменённые пакеты нужно хранить в
каталогах-оверлеях, т.к. изменения в основном каталоге portage будут
потеряны при emerge --sync . |
layman
Layman это утилита позволяющая автоматически устанавливать и обновлять большое количество оверлеев. Это рекомендованный способ для работы с чужими (т.е. не тем, который вы сами ведёте в /usr/local/portage/) оверлеями.
Обновление системы
Одно из основных преимуществ Gentoo — возможность постоянно поддерживать систему с помощью обновлений. Обычно, при обновлении системы раз в несколько дней, для обновления рекомендуют выполнить
emerge --sync
emerge -uDNa world
dispatch-conf # или etc-update
но этого недостаточно! Основная проблема при таком подходе — через некоторое время ряд пакетов (ненужные зависимости и build time зависимости) перестанет обновляться … а в этих пакетах могут быть известные уязвимости, что облегчит взлом системы. Eщё одна проблема связана с обновлением пакетов входящих в toolchain — при этом крайне желательно пересобрать всю систему определённым образом, чтобы избежать странных глюков и получить эффект от обновления toolchain.
В то же время если вы обновляете систему нерегулярно, то при обновлении могут возникать самые необычные проблемы. Связано это с тем, что система обновляется непрерывно, и никто не в состоянии предусмотреть (и протестировать) все нюансы обновления с версии X-месячной давности на текущую.
Если система давно (месяц и более) не обновлялась
Приведение в порядок /var/lib/portage/world
В /var/lib/portage/world должен быть список программ, которые нужно
доустановить плюс к тем, которые уже входят в system (т.е. в текущий
профайл). Но со временем там имеют тенденцию накапливаться лишние записи:
при пересборке пакетов без указания опции emerge -1
, при указании
emerge
конкретной версии/слота пакета, etc. Эти записи могут помешать
правильному обновлению системы, поэтому желательно периодически приводить
/var/lib/portage/world в порядок.
-
В нём не должно быть никаких библиотек, etc., которые не нужны сами по себе, а нужны только для удовлетворения чьих-то зависимостей (чтобы не продолжать устанавливать/обновлять их если они уже станут не нужны по какой-то причине).
-
В принципе, в нём не должно быть пакетов, которые уже входят в system. В то же время, вреда от этого никакого (просто получается некоторое дублирование). Лично мне удобнее держать в /var/lib/portage/world полный список нужных мне пакетов, даже если некоторые из них можно туда и не добавлять, и они всё-равно будут установлены (либо как зависимости других пакетов, либо как часть system).
-
dep -p -w
(входящий в состав пакета udept) поможет найти избыточные пакеты в /var/lib/portage/world (которые всё-равно нужны другим пакетам из /var/lib/portage/world или входят в system).dep
работает более агрессивно, чем стандартные утилиты portage, поэтому использовать его надо с осторожностью. -
regenworld
может помочь восстановить /var/lib/portage/world путем анализа /var/log/emerge.log и генерации на его базе нового /var/lib/portage/world.regenworld
перезапишет текущий /var/lib/portage/world!
Проверка текущих настроек
-
Желательно просмотреть
/etc/portage/*
, т.к. там могут быть уже не актуальные записи мешающие текущему обновлению. -
Обновление профайла.
-
Не каждый Gentoo release включает в себя новый профайл (например, 2004.1 был без профайла).
-
Даже если новый профайл есть, то переходить на него не обязательно (если это будет обязательно, то старый профайл будет deprecated и emerge об этом должен будет громко кричать).
-
Инструкция по обновлению профайла будут выкладываться здесь: http://www.gentoo.org/doc/en/gentoo-upgrading.xml (и, как правило, сводится к изменению симлинка /etc/make.profile).
-
-
Запустить
emerge -uDNpv world
и проверить что USE-флаги для всех пакетов выставлены корректно, и при необходимости скорректировать USE-флаги в /etc/make.conf или /etc/portage/package.use.
Вариант 1: Обычное обновление
Если emerge -uDNpv world
показывает, что будет обновляться пакет входящий
в toolchain (linux-headers, glibc, binutils или gcc), то *ОЧЕНЬ*
рекомендуется полностью перекомпилировать всю систему
или, как минимум, перекомпилировать только необходимое.
emerge --sync # или eix-sync
emerge -uDNa --with-bdeps=y world
Особые пакеты
Иногда обновление пакета требует дополнительных действий. Для таких пакетов выкладываются специальные Upgrade Guides. На эту страничку рекомендуется иногда поглядывать, особенно если обновляется пакет из этого списка и у него меняется старшая/средняя цифра версии.
-
GCC
-
Apache
-
MySQL
-
PHP
-
Java
-
X
Вариант 2: Полная пересборка системы
Полная пересборка обычно выполняется при обновлении пакета(ов) входящих в
toolchain, либо после каких-то глобальных изменений настроек portage
(например, переход на hardened profile или изменение -march в $CFLAGS
в связи с апгрейдом процессора).
-
Если обновляется хотя-бы один из linux-headers, glibc, binutils или gcc, то рекомендуется пересобрать их дважды, после чего весь system, после чего весь world.
-
Цель двойной компиляции toolchain — получить гарантированно стабильный и корректный toolchain не зависящий от предыдущего.
-
Перекомпилировать system и world после этого жёсткой необходимости нет (по крайней мере если остальной софт продолжает работать). Цель перекомпиляции system и world — чтобы весь софт получил потенциальное преимущество от установки нового toolchain. system перекомпилируется перед world из тех-же соображений — при компиляции программ из world используются утилиты из system.
-
-
Если увеличивается первая или вторая цифра версии gcc, то перед второй сборкой нужно переключиться на новую версию через
gcc-config
— иначе новый gcc просто установится параллельно со старым в SLOT но по умолчанию использоваться будет старый. Рекомендуется просматривать Gentoo GCC Upgrade Guide перед обновлением gcc.-
Если вы собираете binutils с USE-флагом "multislot", то вам нужно использовать
binutils-config
аналогичноgcc-config
.
-
-
При сборке system после двойной перекомпиляции toolchain нет необходимости опять компилировать toolchain как часть system. Аналогично при сборке world после system нет необходимости опять компилировать пакеты из system как часть world. Это проще всего обойти через бинарные пакеты и
emerge -k
.
emerge --sync # или eix-sync
# для того, чтобы безопасно использовать `emerge -k` нужно очистить
# каталог с текущими бинарными пакетами
# (напр., переместить его в /tmp/portage-packages)
pkgdir=$(portageq pkgdir)
mv $pkgdir /tmp/portage-packages
install -d -o portage -g portage $pkgdir
# первая сборка toolchain
emerge linux-headers glibc binutils gcc-config gcc
# выбрать новый gcc если он установился в новый слот
gcc-config имя_или_номер_нового_gcc # см. `gcc-config -l`
env-update && source /etc/profile
# компиляция toolchain с созданием бинарных пакетов
emerge -1 libtool
emerge -b glibc binutils gcc portage
emerge -bke system # не компилировать glibc, binutils и gcc
emerge -ke world # не компилировать предыдущие пакеты (включая system)
Вариант 3: Минимальная пересборка при изменении toolchain
Рекомендация от Peter Volkov <pva@gentoo.org>: “Совет пересобирать всё при обновлении чего либо из linux-headers, glibc, binutils или gcc звучит слишком круто. По частям: после обновления linux-headers имеет смысл пересобрать только glibc и это написано в сообщениях после сборки. После пересборки glibc ИМО не нужно ничего делать… Вы не заметите разницы. binutils и gcc единственные кандидаты и то, про gcc, что надо делать явно написано в gcc upgrading guide.”
После обновления
После обновления системы в ней могут оказаться пакеты, которые никто не
использует. Эти пакеты желательно удалить, т.к. они не будут в дальнейшем
обновляться при emerge -uDN world
.
Иногда при этой операции система предлагает удалить нужные пакеты! Поэтому внимательно контролируйте, что вы удаляете. |
emerge -a --depclean # очень осторожно!!!
Если вы обновили не все пакеты (например, из-за того что у вас
замаскирована более новая версия пакета в /etc/portage/package.mask)
или вы не удалили все предложенные emerge -a --depclean
пакеты,
то в системе могут оставаться устаревшие пакеты с известными уязвимостями!
В этом случае необходимо проверить систему с помощью glsa-check
и при
обнаружении уязвимых пакетов обновить их указав emerge
конкретные имена
пакетов.
Используемые здесь glsa-check и revdep-rebuild входят в пакет
gentoolkit. |
glsa-check -l affected
emerge ... # если нужно
После обновления библиотек может потребоваться перекомпилировать пакеты, которые эти библиотеки используют.
revdep-rebuild -i -p
revdep-rebuild
Обновление конфигов.
dispatch-conf # или etc-update
А как устроено …
Обновление критических системных пакетов
Должен быть абсолютно безопасным благодаря использованию SLOT-ов!
Проблемы при установке нового gcc возникнут если новый gcc бинарно
несовместим со старым. Вероятно это связано с тем, что некоторые бинарники
(например, /usr/sbin/mysqld) используют библиотеки gcc (например,
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/libstdc++.so.5). В таких
случаях этим "бинарно несовместимым" версиям gcc назначаются разные
SLOT-ы, и апгрейд на такую версию приведет к установке новой версии без
удаления старой (выбирать, какая версия будет использоваться при
компиляции новых программ можно через gcc-config
).
Имеет смысл на всякий случай сохранить до обновления текущую версию
через quickpkg glibc
. Это позволит вам восстановить работоспособность
системы при таком сценарии:
-
emerge -u glibc
-
Выяснилось, что многие приложения перестали работать.
-
Возвращаем предыдущую glibc - либо через
emerge -K
на этой же системе (если она ещё хоть частично работает), либо через наглую распаковку файла /usr/portage/packages/sys-libs/glibc-2.3.2-r1.tbz2 в корне через bzip2 и tar после загрузки с LiveCD или PXE.
Очень важно, чтобы между обновлением glibc и восстановлением предыдущей версии glibc больше ничего не пересобиралось! |
После апгрейда нужно обязательно запустить revdep-rebuild
, чтобы
пересобрать пакеты слинкованные со старой версией библиотеки.
Перезаписывание существующих файлов при установке пакета
Файлы принадлежат последнему установленному пакету. Все зависит от порядка инсталляции, и не зависит от номера версии или номера ревизии установленных пакетов. Удаление пакета установленного последним и содержащего некий файл, удалит и сам файл (если, конечно, пользователь вручную не изменял этот файл).
Часть файлов (в основном, в /etc/) не заменяется при установке новой
версии пакета (см. “config file protection” в emerge(1)). Такие файлы
должны быть обновлены вручную после установки пакета через утилиту
dispatch-conf
или другие альтернативные утилиты.
Удаление пакетов
Удаление пакетов опасно. Если вы удалите какой-нибудь важный пакет ваша система, скорей всего, перестанет функционировать, а удаление библиотек может неудачно повлиять на работу пакетов. Portage не предупредит вас если вы удалите системный пакет или какую-нибудь зависимость для других пакетов.
При удалении пакета всегда есть риск что этот пакет нужен другим
установленным пакетам. Можно попытаться проверить зависят ли от удаляемого
пакета другие через qpkg -q -I имяпакета
и/или через dep -r имяпакета
.
После удаления можно проверить что он сейчас никому не нужен через
emerge -Dp world
и/или revdep-rebuild -p
.
Переименование пакетов
Иногда пакет переносят из одной категории в другую или переименовывают. Все такие переименования описаны в файлах /usr/portage/profiles/updates/ и обрабатываются системой автоматически.
Поддержка других языков
При сборке пакетов поддерживающих несколько языков устанавливаются только
те, которые перечислены в $LINGUAS
.
LINGUAS="en ru"
Так же можно включать/отключать поддержку дополнительных языков индивидуально для конкретных пакетов с помощью псевдо USE-флага "linguas_язык".
sys-apps/man-pages -linguas_ru
Настройка […] для конкретного пакета
В portage есть универсальный хук: /etc/portage/bashrc.
Этот скрипт вызывается (если существует) перед каждым этапом установки каждого пакета (распаковка, компиляция, etc.). Всю информацию — какой это пакет, какой сейчас выполняется этап, etc. — он получает через переменные окружения.
В нём можно изменять что угодно — $CFLAGS
, используемую версию gcc
(если их установлено несколько в разных SLOT), etc.
Для более простых случаев, когда необходимо просто изменить для пакета переменные окружения, их достаточно добавить в /etc/portage/env/category/package.
Чистка каталога с distfiles
Каталог с distfiles может занимать несколько гигабайт, и со временем занимает всё больше и больше. Есть несколько стратегий для его очистки:
-
Можно просто удалить все файлы в этом каталоге. В этом случае по мере [пере]установки пакетов portage будет выкачивать нужные файлы заново. Быстро, просто, но (со временем) придётся перевыкачать довольно много.
-
Можно удалить все файлы, кроме тех которые нужны для перекомпиляции установленный в данный момент пакетов:
eclean -d distfiles
. При установке нового пакета или изменении USE-флагов существующего может потребоваться выкачать заново файлы, которые были удалены. -
Можно удалить все файлы, которые не используются ни одним пакетом в portage:
eclean distfiles
. При этом освобождается меньше места, чем в других вариантах, но зато гарантированно не придётся ничего перевыкачивать.
Ручная установка в обход portage
Если вы поставили какой-то пакет не через portage (или не ставили, но хотите чтобы portage считал что этот пакет установлен), то нужно добавить полное название этого пакета cate-gory/package-version в /etc/portage/profile/package.provided.
oneshot
Если нужно установить какой-то пакет временно, для эксперимента или
из каких-то соображений (например, если он был нечаянно
удалён или его нужно обновить чтобы закрыть дыру в безопасности),
либо если нужно пересобрать какой-то пакет — всегда нужно использовать
параметр emerge -1
чтобы этот пакет не дописался в
/var/lib/portage/world.
Краткий справочник по параметрам основных команд
-
Полезные фичи qpkg:
qpkg -I # список установленных пакетов qpkg -I -v # список установленных пакетов с версиями qpkg -I -v /pkg- # версия установленного пакета pkg :-) qpkg -q -I ... # вывести пакеты зависящие от заданного # (насколько я понял, это лучше делать через # dep)
-
Полезные фичи emerge ("…" означает список имен программ):
# Информация emerge --info # вывести текущие настройки (в т.ч. USE) emerge -s ... # поиск в имени emerge -p -v ... # какие USE флаги влияют на эту программу и # сколько Kb еще нужно докачать исходников emerge -p -f ... # вывод url откуда можно тянуть sources emerge -p -e ... # показать все зависимости программы без glibc emerge -p -u ... # показать, что будет обновляться emerge -p --depclean # вывести пакеты которых нет в world и от # которых никто не зависит (для удаления) # Выкачка emerge --sync # обновление portage через rsync:// emerge -f ... # только выкачка sources без установки # Установка emerge -p ... # вывод что нужно для установки программы emerge -p -t ... # вывод что нужно для установки программы # (зависимости выводятся в виде дерева) emerge -a ... # то-же что и -p, но после вывода информации # спрашивает продолжить ли выполнять emerge emerge -k ... # установка прекомпилированной программы из # /usr/portage/package/All/ __ЕСЛИ__ там есть # нужная версия программы emerge -K ... # как и -k, но если нужной прекомпилированной # версии нет, то используется какая есть emerge ... # установка программы emerge -u ... # обновить пакет (возможно, на меньшую версию) emerge -uDN world # полный апгрейд системы emerge -C ... # удалить пакет (unmerge). зависимости при # удалении __НЕ__ проверяются!!!
Программа(ы) в "..." могут быть заданы как:
system # базовый набор софта world # весь софт, который ставился ручками + system name # автовыбор лучшей версии программы name "=name-version" # установка именно этой версии "<name-version" # установка лучшей версии меньшей заданной ">name-version" # установка лучшей версии большей заданной "<=name-version" ">=name-version"
При выводе -p могут быть использованы обозначения:
B (blocks) The package listed to the left is blocking the emerge of the package listed to the right N (new) The package is new to your system and will be emerged for the first time R (reemerge) The package isn't new, but needs to be reemerged F (fetch) The package requires that you download the source code manually (for instance due to licencing issues) U (update) The package already exists on your system but will be upgraded UD (downgrade) The package already exists on your system but will be downgraded U- (slot warning) The package you have installed on your system is listed as a package that can not coexist with a different version, but your update does. The update will be installed and the older version will be removed.
TODO
В полезные фичи emerge нужно дописать инфу по --resume и --skipfirst !
Добавить информацию по пакетам eix и portage-utils.