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

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.

Документация по параметрам portage

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.

Example: Установка $MAKEOPTS для двухядерной системы

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.

Примеры записей в /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).

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

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

Cпособы маскировки и демаскировки пакетов

Тестируемые/нерабочие пакеты по умолчанию замаскированы.

Демаскируются через $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-флагов пакеты.

Приоритет 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

Описания USE-флагов

/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), то ОЧЕНЬ рекомендуется полностью перекомпилировать всю систему или, как минимум, перекомпилировать только необходимое.

Example: Обычное обновление

emerge --sync       # или eix-sync
emerge -uDNa --with-bdeps=y world

Reason 1: Problems with SLOTs

This occured to quite a few people that wanted gimp-2 instead of gimp-1.2. Imagine gimp-1.2 marked stable and in SLOT 1, gimp-2 marked unstable and in SLOT 2. Now you do an ACCEPT_KEYWORDS=~x86 emerge gimp and get gimp-2. Later on you consider it's time to update your system with anything similar to emerge -U world. This will install gimp-1.2, because gimp is in the worldfile, and emerge -U doesn't handle the SLOTs here as one might expect it.

Reason 2: Problems if ebuilds are removed from Portage tree

Imagine there are two versions of package foo in portage, foo-1.4 marked stable and foo-1.6 marked unstable. You want unstable and emerge it like gimp above. Some time later you update world like above, but in the meantime foo-1.6.1 came out fixing an important security hole in foo-1.6. Now there are two possibilities:

foo-1.6 got removed from Portage. This results in foo-1.4 getting installed, thus a downgrade instead of "-U"
even worse when foo-1.6 wasn't removed from Portage due to whatever reason: foo-1.6 (the one with the security hole) would stay on your system until something greater than foo-1.6 gets marked stable.

Особые пакеты

Иногда обновление пакета требует дополнительных действий. Для таких пакетов выкладываются специальные 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.

Example: Полная пересборка системы

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`
    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

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

Раньше для этого нужно было использовать дополнительные скрипты вроде enotice или portlog-info, но сейчас достаточно настроить $PORTAGE_ELOG_* в /etc/make.conf.

Эти сообщения рекомендуется внимательно читать, там иногда сообщается критически важная информация.

А как устроено …

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

Апгрейд gcc

Должен быть абсолютно безопасным благодаря использованию 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).

Апгрейд glibc

Имеет смысл на всякий случай сохранить до обновления текущую версию через 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.

Example: Установка $LINGUAS в /etc/make.conf

LINGUAS="en ru"

Так же можно включать/отключать поддержку дополнительных языков индивидуально для конкретных пакетов с помощью псевдо USE-флага "linguas_язык".

Example: Отключение русских man-страниц в /etc/portage/package.use

sys-apps/man-pages -linguas_ru

Настройка […] для конкретного пакета

В portage есть универсальный хук: /etc/portage/bashrc.

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

В нём можно изменять что угодно — $CFLAGS, используемую версию gcc (если их установлено несколько в разных SLOT), etc.

Примеры /etc/portage/bashrc

Для более простых случаев, когда необходимо просто изменить для пакета переменные окружения, их достаточно добавить в /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.