[gentoo-user-ru] Описание portage

[Alex Efros]

Hi!

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

К примеру, ответ на вопрос: "как обновить систему?" в виде "emerge world"
меня категорически не устраивал, т.к. после сборки своего дистрибутива я
в полной мере осознавал что так просто это делаться не может, если,
конечно, вам интересно чтобы после обновления система всё ещё работала. :)

Тогда я начал составлять для себя некое описание portage, просто чтобы
лучше понимать как им пользоваться. Было это года полтора назад.
В процессе составления такого описания, в какой-то момент понимание что
и как делать у меня появилось и описание с тех пор я обновлять и
прорабатывать TODO перестал. Поскольку недавно я это осознал, и понял
что до удобоваримого вида я его уже не доведу, и переводить на
английский, как планировал, не буду, то я решил его запостить в том виде,
в котором оно сейчас есть. Может быть оно кому-нить пригодится. Если нет - 
ну что-ж, тогда сорри за траффик. :)

P.S. Лицензия: с этим тектом можно делать всё, что хотите. :)

P.P.S. Если у кого будут вопросы по тексту - например, почему я не
пользуюсь RC-скриптами, или наоборот, ответы на вопросы в моём разделе
"вопросы нуждающиеся в уточнении" - you are welcome. :)


***************************************************************
*** Устройство и работа portage с точки зрения пользователя ***
***************************************************************

Здесь собрана информация по нюансам использования portage из самых разных
источников: документации, web-сайтов, Gentoo'шных форумов, maillist-ов и
личного опыта. В некоторых местах (особенно где английский текст) -
это просто cut&paste из этих источников.

Предполагается, что базовые знания по portage уже есть, и, например,
рассказывать что такое `emerge sync` или USE-флаги не нужно.

Основной упор при сборе информации делался на:
- описание разницы между разными способами выполнить одну и ту-же задачу
  (с примерами/аргументами описывающими последствия выполнения задачи "не
  правильным" способом)
- составление "рецептов" по решению типовых задач
- полноту описания отдельных аспектов portage

NOTE Всё что касается RC-скриптов я не изучал вообще т.к. я ими не пользуюсь.

*** Настройка portage

# FEATURE: Установить $CFLAGS для оптимизации компиляции программ.
# FEATURE: Выбрать стабильную или тестовую версию пакета.
# FEATURE: Выбрать опциональные возможности пакета включаемые при компиляции
#	   (USE-флаги).
# FEATURE: Замаскировать/демаскировать выбранные версии пакетов.
Настраивать portage можно через:
 *  /etc/make.profile (симлинк указывающий на текущий профайл)
 *  /etc/make.conf (пользовательские настройки)
 *  /etc/portage/ (пользовательские изменения для отдельных пакетов и профайла)
 *  переменные окружения
		Изменять переменные окружения не рекомендуется т.к.
		эти изменения не будут учтены при последующих
		перекомпиляциях пакетов.
Текущие настройки выдаёт `emerge info`. Они являются результатом объединения
глобальных настроек (перечисленных ниже) и пользовательских настроек
(перечисленных выше). Файлы с глобальными настроками редактировать нельзя.
Глобальные настройки можно посмотреть в:
 *  /etc/make.globals (глобальные настройки)
 *  /usr/portage/* (файлы с разными настроками, в т.ч. package.mask)
 *  /usr/portage/ВАШ/ТЕКУЩИЙ/ПРОФАЙЛ/
		Плюс все профайл-каталоги которые этот профайл "наследует"
		(имя унаследованного профайла-каталога находится в
		файле parent, а сам каталог с профайлом определяется
		через симлинк /etc/make.profile - см. выше).

Документация по возможным параметрам portage:
 *  `man make.conf`
 *  `man portage`
 *  /etc/make.conf.example

*** Выбор устанавливаемых пакетов

# FEATURE: Можно выбрать, какую версию нужной программы устанавливать.
# FEATURE: Каждый ebuild скрипт может быть помечен как
# стабильный/тестируемый/не работает отдельно для каждой архитектуры.
Portage-у, для установки определенной версии определенной программы, нужен
специальный скрипт (ebuild) в котором описаны специфичные для этой
программы/версии команды компиляции/инсталляции, опциональные возможности и
текущий статус: стабильная/нестабильная/неработающая версия.
Одновременно в portage может быть несколько разных версий, часть из которых
может быть помечена как стабильные, часть как нестабильные, etc. и всегда
можно форсировать установку любой из этих версий пакета. По умолчанию portage
будет устанавливать либо максимальную из стабильных версий, либо из
нестабильных - в зависимости от настроек.

Для установки нестабильной или нерабочей версии нужно разрешить их
индивидуально для каждого пакета в /etc/portage/package.keywords .
Кроме того можно глобально разрешить установку нестабильных версий для
всех пакетов в настройках portage, специально для любителей потестировать
самые свежие глюки. :)

ebuild may be marked '-arch', meaning "does not work", '~arch', meaning
"unstable", or 'arch', meaning "stable".

Примеры записей в /etc/portage/package.keywords :
    cate-gory/package
	разрешает использовать любые "нестабильные" версии пакета (кстати, в
	документации я такого синтаксиса не нашёл - имеется в виду возможность
	не указывать ~x86, что очень удобно)
    =cate-gory/package-version ~x86
	разрешает использовать именно эту "нестабильную" версию пакета, не будет
	пытаться downgrade-нуть её на предыдущую стабильную при emerge -u, и не
	будет автоматически апгрейдить её на более новые "нестабильные" версии
    ~cate-gory/package-version ~x86
	где version не включает номер ревизии (-rX) будет работать как и
	предыдущий вариант с одним исключением - автоматические апгрейды на
	более новые "нестабильные" ревизии этой-же (!!!) версии пакета будут
	разрешены

Некоторые версии программ могут быть замаскированы:
 *  для всех профайлов: /usr/portage/profiles/package.mask
 *  для текущего профайла: /etc/make.profile/packages
 *  пользователем: /etc/portage/package.mask
 *  пользователем при предыдущей установке этого пакета: /var/lib/portage/world
		Это может произойти если при emerge указывалась конкретная
		версия пакета через = (или допустимые диапазоны версий
		через <>) без использования --oneshot, и в файл world
		была добавлена строка содержащая эти ограничения.
Для установки замаскированного пакета его нужно демаскировать: для первых
двух случаев через /etc/portage/package.unmask для третьего просто убрав
ограничение из /etc/portage/package.mask а в последнем случае убрав ограничение
из /var/lib/portage/world .

You can "pin" a package. Just put ">=app-grp/appname-x.y.z" into
/var/lib/portage/world and emerge -u world won't try to downgrade, or use
= instead of >= and it will never try to change the version at all.

# FEATURE: Можно иметь свои локальные наборы ebuild скриптов.
Ebuild-скрипты должны находится либо в основном каталоге portage,
либо в одном из дополнительных каталогов portage.
Основной каталог задается в настройках portage как PORTDIR (обычно это
/usr/portage/). Дополнительные каталоги можно указать в настройках portage
как PORTDIR_OVERLAY (обычно это один каталог: /usr/local/portage).
Если ebuild для одной и той-же версии программы будет найден и в основном
каталоге, и в дополнительных - будет использован скрипт из дополнительного
каталога.
		Свои ebuild скрипты нужно хранить в дополнительных каталогах,
		т.к. изменения в основном каталоге будут потеряны при
		`emerge sync`. Это же касается изменений основных ebuild-ов -
		нужно сначала скопировать их из основного каталога в
		дополнительный и уже там изменять.

# FEATURE: Все программы сгруппированы по категориям.
Внутри каталога portage ebuild скрипты сгруппированы по категории и
названию программы: /usr/portage/CATEGORY-NAME/SOFT/NAME-VERSION.ebuild .
Иногда программу переносят из одной категории в другую, все такие
переименования описаны в файлах /usr/portage/profiles/updates/* .

*** USE-флаги

USE-флаги бывают "глобальные" (используемые более чем одним пакетом) и
"локальные" (используемые только одним пакетом). Их описания в файлах:
/usr/portage/profiles/use.desc и /usr/portage/profiles/use.local.desc .

Дополнительные USE-флаги могут быть добавлены автоматически после установки
соответствующего софта: /etc/make.profile/use.defaults (но они перекрываются
любыми юзерскими настройками - make.conf, /etc/portage/ и $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-флагов рекомендуется пересобрать все пакеты,
на которые влияют эти флаги: `emerge --newuse world`, после чего
сделать что-нить типа
    emerge -p depclean
чтобы удалить ставшие лишними из-за изменения USE-флагов пакеты.

*** Полное обновление системы

*   Приведение в порядок /var/lib/portage/world . В world должен быть список
    программ, которые нужно доустановить плюс к тем, которые уже входят в 
    "system" (т.е. в текущий профайл).
    -	в world не должно быть никаких библиотек, etc., которые не нужны
	сами по себе, а нужны только для удовлетворения чьих-то зависимостей
	(чтобы не продолжать устанавливать/обновлять их если они уже станут
	не нужны по какой-то причине)
    -	программ, которые уже входят в "system" не должно быть в world
	(почему, кстати, и где это написано? и как быть с тем, что содержимое
	system может меняться при изменении профайла?)
    -	в world нельзя указывать определенную версию софта, это лучше делать
	в /etc/portage/package.mask (а это почему и где написано?)
    -	скрипт `regenworld` может помочь восстановить world путем анализа
	/var/log/emerge.log и генерации на его базе файла world
	(он перезапишет текущий world!)
    -	скрипт `dep -p -w` поможет найти избыточные записи в world
	(которые всё-равно нужны другим записям в world или входят в system).
*   Перед серьёзными обновлениями желательно просмотреть /etc/portage/* ,
    т.к. там могут быть уже не актуальные записи мешающие текущему обновлению.
*   Обновление profile.
    -	Не каждый Gentoo release включает в себя новый profile (например,
	2004.1 был без profile).
    -	Даже если новый profile есть, то переходить на него не обязательно
	(если это будет обязательно, то старый профайл будет deprecated и
	emerge об этом должен будет громко кричать).
    -	Инструкция по обновлению profile будут выкладываться здесь:
	http://www.gentoo.org/doc/en/gentoo-upgrading.xml
	и как правило сводиться к изменению симлинка /etc/make.profile .
*   USE-флаги.
    -	Запустить `emerge -uDpv --newuse world` и проверить что USE-флаги для
	всех пакетов выставлены корректно, и при необходимости скорректировать
	USE-флаги через /etc/make.conf или /etc/portage/package.use .
*   Запуск обновления системы (если не нужно ли обновлять toolchain).
    -	Если `emerge -uDpv --newuse world` показывает что будет обновляться
	пакет входящий в toolchain (linux-headers, glibc, binutils или gcc), то
	крайне рекомендуется полностью перекомпилировать всю систему -
	см. следующий пункт - а иначе можно вместо следующего пункта просто
	запустить:
	    emerge -uDav --newuse world
    -	Некоторые причины не использовать emerge -U вместо -u :
		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 "-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:
	 a) foo-1.6 got removed from Portage. This
	    results in foo-1.4 getting installed, thus a downgrade instead of
	    "-U"
	 b) 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.
*   Обновление одного из пакетов входящих в toolchain.
    - Если обновляется хотя-бы один из linux-headers, glibc, binutils или gcc,
      то рекомендуется пересобрать их дважды, после чего весь system, после
      чего весь world.
      Цель двойной компиляции toolchain - получить гарантированно стабильный и
      корректный toolchain не зависящий от предыдущего.
      Перекомпилировать system/world после этого жёсткой необходимости нет,
      по крайней мере если остальной софт продолжает работать (возможно даже
      используя библиотеки из старого toolchain - см. предыдущие пункты об
      апгрейде).
      Цель перекомпиляции system/world - чтобы весь софт получил потенциальное
      преимущество от установки нового toolchain. system перекомпилируется
      перед world из тех-же соображений, т.к. при компиляции программ из world
      используются утилиты из system.
    - Если увеличивается первая или вторая цифра версии gcc, то перед второй
      сборкой нужно переключиться на новую версию через gcc-config - иначе
      новый gcc просто установится параллельно со старым в "новый слот" но
      по умолчанию использоваться будет старый.
    - При сборке system после двойной перекомпиляции toolchain нет
      необходимости опять компилировать toolchain как часть system.
      Аналогично при сборке world после system нет небходимости опять
      компилировать пакеты из system как часть world. Это можно попробовать
      обойти либо вручную, либо используя скрипты из 
      http://forums.gentoo.org/viewtopic.php?t=282474 либо через бинарные
      пакеты и `emerge -k` (я предпочитаю последний вариант).
    - Итого, рекомендованный набор команд:
	# для того, чтобы безопасно использовать `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 -b glibc binutils gcc portage
	emerge -bke system  # не компилить glibc, binutils и gcc
	emerge -bke world   # не компилить предыдущие пакеты (включая system)
    - Чисто теоретически существует пакет binutils-config, который когда-нить
      может потребоваться использовать аналогично gcc-config.
*   Обновление безопасности.
    - Даже после `emerge -uDav --newuse world` в системе могут оставаться
      устаревшие пакеты с дырами в безопасности - в слотах!
	    glsa-check -l | grep '\[N\]'
	    emerge ...			# если нужно
*   Удаление не используемых пакетов.
    - После обновления системы в ней могут оказаться пакеты, которые никто
      не использует. Эти пакеты желательно удалить, т.к. они не будут в
      дальнейшем обновляться при `emerge -uDav --newuse world`.
	    emerge -a depclean		# очень осторожно!!!
*   После обновления библиотек может потребоваться перекомпилировать
    программы, которые эти библиотеки используют:
	    rm /root/.revdep-rebuild*.?_*
	    revdep-rebuild -p
	    revdep-rebuild
*   Обновление конфигов.
	    dispatch-conf
*   Если используется runit-init и обновлялся пакет baselayout, то нужно
    восстановить /sbin/init:
	    ls -l /sbin/*init*
	    if (/sbin/init это бинарник, а не симлинк) {
		mv /sbin/init /sbin/init-sysv
		ln -s runit-init /sbin/init
	    }
*   Отслеживание важных сообщений при установке пакетов.
    -	В процессе `emerge world` выдаётся очень много сообщений, причём
	важные комментарии перемешаны с командами компиляции, и отследить
	их при сборке нескольких пакетов одновременно не возможно.
	Но все эти сообщения можно получить из log-файлов после окончания
	установки `emerge world`. Для этого нужно использовать либо
	`enotice` либо `portlog-info`.

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

*   Апгрейд 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`).
*   Апгрейд gcc/glibc/других критических библиотек.
    - Перед апгрейдом может иметь смысл отключать AUTOCLEAN (см. `man
      make.conf`) чтобы старая версия glibc не была удалена до того как
      весь зависящий от неё софт не будет пересобран с новой версией.
      После того как всё будет пересобрано можно будет удалить старые версии
      через `emerge --clean`.
    - Так-же может иметь смысл на всякий случай сохранить до обновления
      текущие версии через `quickpkg glibc`. Тогда её можно будет
      восстановить в случае проблем с новой версией: 
      `emerge -k /usr/portage/packages/sys-libs/glibc-2.3.2-r1.tbz2`.
    - После апгрейда нужно обязательно запускать `revdep-rebuild`, чтобы
      пересобрать проги зависящие от старой версии обновляемой библиотеки.
*   Апгрейд любого из пакетов входящих в toolchain (linux-headers, glibc,
    binutils, gcc) или перекомпиляция их с серьёзными отличиями в USE-флагах
    (напр. nptl, hardened).
    - Во избежание глюков крайне рекомендуется не экономить на времени
      компиляции и сделать всё как описано в разделе "Полное обновление
      системы", вариант с обновлением toolchain.

*** Перезаписывание существующих файлов при установке пакета

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

Описание работы фичи "config file protection", благодаря которой часть файлов
(в основном, в /etc/) не переписывается автоматом при установке новой версии
пакета можно прочитать в `emerge --help config`. Такие файлы должны быть
обновлены вручную после установки пакета через утилиту `dispatch-conf`
или другие альтернативные утилиты (но использовать `etc-update` крайне
не рекомендуется!).

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

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

При удалении пакета всегда есть риск что этот пакет нужен другим
установленным пакетам. Можно попытаться проверить зависят ли от удаляемого
пакета другие через `qpkg -q -I имяпакета` и/или через `dep -r имяпакета`.
После удаления можно проверить что он сейчас никому не нужен через
`emerge -Dp world` и/или `revdep-rebuild -p`.

*** Разное

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

Значение CHOST в /etc/make.conf можно изменять только при установке из stage1,
до запуска bootstrap.

You can always pass a full path to an ebuild to emerge, and this will bypass
all mask checking, so this is another quick way to install one masked package.
Но при этом пишут, что запускать `emerge /path/to/file.ebuild` нельзя.
В частности, в `man emerge`: "WARNING: The implementation of
emerge /path/to/ebuild is broken and so this syntax shouldn't be used.".

TODO
Просмотреть:
    http://forums.gentoo.org/viewtopic.php?t=171464
Сравнить (поиск по форуму) cfg-update и dispatch-conf; colordiff! etc.

Куча дополнительного софта для работы с portage:
/usr/portage/app-portage/* :) плюс
http://gentooexperimental.org/script/repo/list
- enotice
- portlog-info (вероятно, не нужен при использовании enotice) 
- gest (сравнить с `genlop -p` и `splat -s`)
- glcu (для серверов):
    http://www.panhorst.com/glcu/
    http://forums.gentoo.org/viewtopic-p-2123630.html
- find-old-distfiles (довести до ума)
- dep
- cruft, cruft2.py (проверить на безопазность и полезность)

*   Обновление пакетов из-за секьюрити
    -	glsa-check
    -	ручной inject некоторых glsa из-за багов glsa-check

*   Еще одна вещь, о которой следует упомянуть, - это команда

    emerge ingect =pkg-PV-PR

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

    emerge -pu world

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

    emerge inject pkg-PV-PR
	NB! Начиная с 2.0.51:
	The use of --inject is deprecated for the time being. Injecting
	packages should now be done by adding the package to
	/etc/portage/profile/package.provided using the full name
	(<category>/<name>-<version>) instead.
	Для обнаружения inject-нутых пакетов и переноса их в package.provided
	можно использовать:
	http://www.stud.uni-karlsruhe.de/~uxhz/gentoo/misc/einjected

    и затем спокоино выполнять

    emerge -u world

*** Краткий справочник по параметрам основных команд

*   Полезные фичи etcat:

    etcat -v ...		# вывести все версии пакета ... в портаже
    etcat -u ИМЯ		# с какими настройками USE (только из влияющих
				# на эту программу) была установлена программа

*   Полезные фичи qpkg:

    qpkg -I			# список установленных пакетов
    qpkg -I -v			# список установленных пакетов с версиями
    qpkg -I -v /pkg-		# версия установленного пакета pkg :-)
    qpkg -q -I ...		# вывести пакеты зависящие от заданного
				# (насколько я понял, это лучше делать через
				# dep)

*   Полезные фичи emerge ("..." означает список имен программ):

    TODO В полезные фичи emerge нужно дописать инфу по --resume и --skipfirst !

    # Информация
    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 -uD --newuse 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.

*** Вопросы, нуждающиеся в уточнении

Чистка distfiles.

Разобраться, включен ли у меня sandbox и достаточно ли этого для безопасной
компиляции (что такое user* FEATURES и нужны ли они вместе/вместо sandbox).

Интересно, как будет ставиться прога, которой нужно установить suid-ные
root-овые файлы если её собирать так:
    FEATURES="userpriv usersandbox sfperms"

Что такое `fixpackages`? Нужно ли его запускать ручками?

/etc/portage/bashrc подчитывается перед установкой каждой программы, даже если
emerge ставит их много одновременно?
http://home.jesus.ox.ac.uk/~ecatmur/gentoo/etc/portage/bashrc написан в
расчете именно на это (изменяет $CFLAGS индивидуально для ethereal).

Насколько безопасно в /etc/portage/rsync_excludes засунуть:
/usr/portage/metadata/cache

portageq envvar NOCOLOR

Проверить действительно ли --metadata ускоряет рассчёт зависимостей
для вытянутого архива с portage (аналогично можно проверить --regen).

*** Полезные файлы и программы

Одна из gentoo-шных утилит, которой стоит пользоваться: `env-update`.
(Она вызывается автоматом после установки любого пакета.)

TODO обновить этот список для последней версии portage перед тем как его
     описывать!
- описать все файлы/каталоги используемые в portage с точки зрения их задач:
    /var/cache/edb/*
    /var/db/pkg/*
    /var/log/portage/
    /var/log/emerge.log
    /usr/portage/distfiles/
    /usr/portage/metadata/*
    /usr/portage/packages/
    /usr/portage/profiles/*
    /usr/portage/profiles/updates/
    /usr/portage/rpm/
    /usr/portage/scripts/*
    /usr/local/portage/
    /etc/env.d/
    /etc/modules.d/
    /etc/dispatch-conf.conf
    /etc/etc-update.conf
- описать полезные программы используемые для манипуляции этими файлами:
    modules-update
    /usr/bin/xpak -> ../lib/portage/bin/xpak 1087030209
    /usr/bin/repoman -> ../lib/portage/bin/repoman 1087030209
    /usr/bin/g-cpan.pl -> ../lib/portage/bin/g-cpan.pl 1087030209
    /usr/bin/portageq -> ../lib/portage/bin/portageq 1087030209
    /usr/bin/emerge -> ../lib/portage/bin/emerge 1087030209
    /usr/bin/quickpkg -> ../lib/portage/bin/quickpkg 1087030209
    /usr/bin/tbz2tool -> ../lib/portage/bin/tbz2tool 1087030209
    /usr/sbin/fixpackages -> ../lib/portage/bin/fixpackages 1087030209
    /usr/sbin/env-update -> ../lib/portage/bin/env-update 1087030209
    /usr/sbin/etc-update -> ../lib/portage/bin/etc-update 1087030209
    /usr/sbin/emerge-webrsync -> ../lib/portage/bin/emerge-webrsync 1087030209
    /usr/sbin/regenworld -> ../lib/portage/bin/regenworld 1087030209
    /usr/sbin/archive-conf -> ../lib/portage/bin/archive-conf 1087030209
    /usr/sbin/ebuild -> ../lib/portage/bin/ebuild 1087030209
    /usr/sbin/dispatch-conf -> ../lib/portage/bin/dispatch-conf 1087030209
    /usr/sbin/ebuild.sh -> ../lib/portage/bin/ebuild.sh 1087030209
    /usr/sbin/pkgmerge -> ../lib/portage/bin/pkgmerge 1087030209
    /usr/lib/portage/bin/domo
    /usr/lib/portage/bin/queryhost.sh
    /usr/lib/portage/bin/fix-db.py
    /usr/lib/portage/bin/fixdbentries
    /usr/lib/portage/bin/sandbox
    /usr/lib/portage/bin/chkcontents
    /usr/lib/portage/bin/pkgmerge.new
    /usr/lib/portage/bin/db-update.py
    /usr/lib/portage/bin/extra_functions.sh
    /usr/lib/portage/bin/emergehelp.py
    /usr/lib/portage/bin/pkgname
    /usr/lib/portage/bin/find-requires
    /usr/lib/portage/bin/fixvirtuals
    /usr/lib/portage/lib/sandbox.bashrc
    /usr/share/man/man5/ebuild.5.gz
    /usr/share/man/man5/portage.5.gz
    /usr/share/man/man5/make.conf.5.gz
    /usr/bin/euse
    /usr/bin/qpkg
    /usr/bin/etcat
    /usr/bin/revdep-rebuild
    /usr/bin/glsa-check
    /usr/bin/dep-clean
    /usr/bin/equery
    /usr/bin/ewhich
    /usr/bin/pkg-size
    /usr/sbin/pkg-clean
    /usr/sbin/mkebuild
    /usr/share/doc/gentoolkit-0.2.0_pre8/*/README
    genlop
    esearch
    /usr/bin/ebump
    /usr/bin/gensync
    /usr/bin/epkgmove
    /usr/bin/echangelog
    /usr/bin/ekeyword
    ufed


-- 
			WBR, Alex.
-- 
gentoo-user-ru@g.o mailing list