Инструкция - как потерять пакет в системе

Спасибо, попробую, но уже наверное завтра.

Всё, что ставилось через emerge <что-то там> без --oneshot

именно так.
(но не совсем. Я изменяю версии пакетов и обновляю систему.)

Могу провести эксперимент глубже:
назовем установленный виртуальный ебилд V-1. А теряющийся пакет X-1
Последовательность действий.
Удалить пакет X-1.
Составить следующий виртуальный ебилд V-2 без X-1.
Установить ебилд V-2.
Установить размаскирование виновного пакета X-1.
Составить следующий виртуальный ебилд V-3 c зависимостью от X-1 и установить.
Тогда он по зависимостям должен установить X-1.
Удалить размаскировку X-1.
Проверить видит ли система emerge пакет X-1.

(Если уж так интересно)

1. В world писать отсебятину (комменты) и делать свое форматирование не принято.
2. Управлять надо зверинцем разномастных и даже разных по архитектуре и профилям компов.
3. Умозрительно пакеты делятся на группы (по назначению, зависимостям тд и тп)
4. Хорошо бы держать историю изменения состава.

Повторяю portage-2.2 замаскирован, да и сеты привязываются к машине (причем даже не машине, а конкретной версии установленной системы, а ее может быть и не одна).

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

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

Повторяю мне такое управление просто удобнее.

Но! Всё это чистой воды ФДУД, ФЛУД и ничего кроме ФЛУДА. Никого идти за собой данным путем я не призываю.

ПРОБЛЕМА в другом. Есть понятие виртуального пакета. Так вот он на мое ощущение (а ощущение - потому как я не уверен в правильной расценке своих наблюдений) содержит достаточно серьезную багу. И решить данной темой я хотел именно эту багу. И не более того.

Я бы не сильно обратил на это внимание, если бы не повышенная ответственность по отказоустойчивости + наличие таких же пакетов в официальном дереве portage.

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

Это всё объяснения - почему надо решать этот вопрос.
А мне бы хотелось решать именно сам вопрос.

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

PS. Сегодня не удалось проверить чистую работу DEPEND="${RDEPEND}".

Более того, и --depclean не очень нужен. Не так, как с метапакетами.

% emerge -pC @kdeadmin-4.2

>>> These are the packages that would be unmerged:

 kde-base/ksystemlog
    selected: 4.2.3 
   protected: none 
     omitted: none 

 kde-base/kuser
    selected: 4.2.3 
   protected: none 
     omitted: none 

 kde-base/knetworkconf
    selected: 4.2.3 
   protected: none 
     omitted: none 

 kde-base/kcron
    selected: 4.2.3 
   protected: none 
     omitted: none

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

То что virtual/httpd-basic - не корректный пример, я уже понял утром.

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

Исходный ебилд виртуального пакета я привожу. (Правда не сам ебилд, а его шаблон). http://www.gentoo.ru/node/15040#comment-105300

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

То что world перезаписывается, означает что, внесение в него комментариев бессмысленно.

PS. То что мне тут объясняют, что выбранный мною метод неверен, но не предлагают "правильного" решения от авторов портежа, сильно отвлекает от решения данного бага.

PPS. Всё некогда продолжить исследования. Но надеюсь выходные помогут. Возникла мысль еще одного эксперимента - внести этот пакет прямо в world. И посмотреть, что скажет обновление.