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

Обнаружил такую неприятность.
И считаю ее крайне критической.
Заранее извиняюсь за многословность.

(Обнаружил ситуацию как потерять пакет для видимости системы emerge. И что печально - это сервис, то есть - прямая уязвимость системы)

Предыстория.
Для администрирования состава пакетов использую виртуальные пакеты.
В них включаю желаемые пакеты по зависимостям.
Использую стабильную ветвь. Размаскирую только желаемые.

В системе таким образом был установлен пакет.
Каким-то образом у него исчезла размаскировка. (Возможно возможно в portage он замаскировался, возможно сам потерял запись в /etc/portage/package.keywords)

Система прошла за это время даже полную пересборку по причине замены gcc.

Что получилось на данный момент.
emerge -av1 packet_name. Отказался собирать этот пакет по причине его маскировки.
Задумался о том, что что-то не так. Система регулярно в последнее время проходила обновления (emerge -avuDN world и emerge -av --depclean). И ни разу не было проблем ни с установкой, ни с попыткой удалить пакет, ни с его отсутствием в системе.

Исследования показали.
emerge -e world не содержит этого пакета.
eix packet_name содержит [D] перед пакетом. В мане описания не нашел.
emerge --depclean ни на что не жалуется.
При восстановлении размаскировки пакета в /etc/portage/package.keywords он начинает обслуживаться системой.

Мои выводы.
Таким образом можно свободно потерять пакет в системе (особенно для пользователей стабильной ветви)
Стабильность работы данного пакета можно поставить под вопрос, так как он не прошел пересборку в критический момент ( даже с флагом --emptytree ).

PS. Возражения - не использовать самописные виртуальные пакеты - не принимаю. Они существуют не только моего исполнения. Что, на самом деле, еще более отягощает ситуацию.
PPS. На ситуацию наткнулся чисто случайно, хотел попроще посмотреть ключи пакета.

А посмотреть

А посмотреть почему замаскирован пакет слабо? :)

Working on Gentoo Linux for Asus P535 and Qtopia :-)

не в тему.

Дело не в том, почему пакет замаскировали. А почему он полностью выпал из видимости emerge -e. То есть он и не попытается пересобраться при изменении в тулчейне. (это как пример)

К тому же, я сознательно обезличил название пакета, так как оно не принципиально к вопросу.

Антиресно, IMHO ССЗБ

Антиресно, IMHO ССЗБ :(
emerge --info,virtual ebuild,наименование потерянного пакета в студию, пожалуйста.

"Исследования показали.emerge -e world не содержит этого пакета" - А почему он должен его содержать ?
"eix packet_name содержит [D] перед пакетом. В мане описания не нашел" [D] -requre delete,т.е надо удалить (причин много)
"emerge --depclean ни на что не жалуется" А должен ?

" * Depclean may break link level dependencies. Thus, it is
* recommended to use a tool such as `revdep-rebuild` (from
* app-portage/gentoolkit) in order to detect such breakage.
*
* Always study the list of packages to be cleaned for any obvious
* mistakes. Packages that are part of the world set will always
* be kept. They can be manually added to this set with
* `emerge --noreplace `. Packages that are listed in
* package.provided (see portage(5)) will be removed by
* depclean, even if they are part of the world set.
*
* As a safety measure, depclean will not remove any packages
* unless *all* required dependencies have been resolved. As a
* consequence, it is often necessary to run `emerge --update
* --newuse --deep world` prior to depclean.
"

P.S portage это не программа, это каша из разных глюков,интерфейсов,и не доделаных фич и багов,
Но лучше для sourced based ничего нет

Compute:
Bosch M2.8.1 -> custom Bosch M2.8.3 clone from Russia.
Speed about 260 km,Ram 2 pers.,HDD - 70 kg,210 FLOPS ;)

да...

slepnoga написал(а):
P.S portage это не программа, это каша из разных глюков,интерфейсов,и не доделаных фич и багов,
Но лучше для sourced based ничего нет

истерики прекращаем. с таким настроением смело отправляйся юзать paludis и поставь себе exherbo

evadim написал(а):slepnoga

evadim написал(а):
slepnoga написал(а):
P.S portage это не программа, это каша из разных глюков,интерфейсов,и не доделаных фич и багов,
Но лучше для sourced based ничего нет

истерики прекращаем. с таким настроением смело отправляйся юзать paludis и поставь себе exherbo

Это вольное преложение статьи со старого fantoo

Compute:
Bosch M2.8.1 -> custom Bosch M2.8.3 clone from Russia.
Speed about 260 km,Ram 2 pers.,HDD - 70 kg,210 FLOPS ;)

виртуальный

виртуальный пакет

DESCRIPTION="Auto packs"
HOMEPAGE=""
SRC_URI=""
LICENSE="GPL-2"
SLOT="0"
KEYWORDS="alpha amd64 arm hppa ia64 mips ppc ppc64 sh sparc x86 ~x86-fbsd"
IUSE=""
RDEPEND="
AAAA/aaaa  BBBB/bbbb
"
DEPEND=""

где
AAAA,BBBB название категорий,
aaaa,bbbb название пакетов без версий

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

Это если поможет http://pastebin.com/m1adc19f emerge --info

revdep-rebuild возможно где-то и поможет. (странно, почему он не входит в system)

Пожелания удалить пакет от emerge --depclean не поступало.
emerge -avuDN world и emerge -ave world тоже ни на что не жаловались. А по-моему представлению должны были бы поднять бучу до тех пор пока я не решу проблему:
1. удалив пакет - и этот, и другой, который его просит
2. размаскировав пакет

PS. Если мне не получится в свободное время смоделировать такую ситуацию с другим пакетом, то посчитаю данное поведение временным и единичным сбоем emerge. Для этого целенаправленно отказываюсь от обновления системы, пока наблюдаю ситуацию стабильной.

RDEPEND=" AAAA/aaaa

RDEPEND="
AAAA/aaaa  BBBB/bbbb
"
DEPEND=""

Меня это смущает. Может, в этом дело? Я бы написал DEPEND="${RDEPEND}"

Текстовый редактор vi имеет два режима работы: в первом он пищит, а во втором — всё портит.

krigstask

krigstask написал(а):
RDEPEND="
AAAA/aaaa  BBBB/bbbb
"
DEPEND=""

Меня это смущает. Может, в этом дело? Я бы написал DEPEND="${RDEPEND}"

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

Попробуй добавить

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

в сообщении от 12 Май, 2009 -

в сообщении от 12 Май, 2009 - 00:45 уже писал, что вариант не прошел.

никуда он полностью не выпал.

никуда он полностью не выпал. его легко можно "достать" командой
emerge -pvuND --with-bdeps=y world
эта команда сообщит о том что надобы размаскировать/просто понизит версию

evadim написал(а):никуда он

evadim написал(а):
никуда он полностью не выпал. его легко можно "достать" командой
emerge -pvuND --with-bdeps=y world
эта команда сообщит о том что надобы размаскировать/просто понизит версию

спасибо за совет
emerge -pvuND --with-bdeps=y world
но он, не помогает
Предложил обновить еще пару пакетов, но невидимки среди них нет.

#emerge -av

#emerge -av packet_name

These are the packages that would be merged, in order:

Calculating dependencies... done!

!!! All ebuilds that could satisfy "xxx-xxx/xxxx" have been masked.
!!! One of the following masked packages is required to complete your request:
- xxx-xxx/xxxx-X.XX (masked by: ~amd64 keyword)

For more information, see the MASKED PACKAGES section in the emerge
man page or refer to the Gentoo Handbook.

Тогда вопрос для знатоков:

Тогда вопрос для знатоков: что входит в world.
Ответ "все пакеты в системе " не правилен по определению

Compute:
Bosch M2.8.1 -> custom Bosch M2.8.3 clone from Russia.
Speed about 260 km,Ram 2 pers.,HDD - 70 kg,210 FLOPS ;)

Всё, что ставилось через

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

Текстовый редактор vi имеет два режима работы: в первом он пищит, а во втором — всё портит.

Нефиг было использовать

Нефиг было использовать виртуальные пакеты. Зависимости не записываются в world. В world - все то, что ты набирал руками. При emerge -av foobar сам пакет при этом попадет в мир, а его зависимости - нет. То, что ты теряешь неучтенные зависимости - виноват только ты сам.

Не грусти, товарищ! Всё хорошо, beautiful good!

на свежую голову, с утра,

на свежую голову, с утра, перечитал первый пост.

Kevol написал(а):
Для администрирования состава пакетов использую виртуальные пакеты.
В них включаю желаемые пакеты по зависимостям.
Использую стабильную ветвь. Размаскирую только желаемые.

Выглядит бредово. Я правильно понял что ты сам лепиш виртуальные пакеты включая в них некоторый набор софта? Если да, то перестань делать хаки, поставь portage-2.2 в котором есть @set - "наборы" пакетов, которые весьма похожи на метапакеты, но какраз и предназначены примерно для того что ты делаеш.
Виртуальные пакеты предназначены совсем для другого - для установки зависимости некоей программы на одиу из нескольких возможных реализаций того что ей нужно.

Ну не желаю я использовать

Ну не желаю я использовать размаскированный sys-apps/portage.
Почему таки он до сих пор не считается стабильным? ;)

С чего это написание своих ебилдов считается хаком? Тем более, что мне так удобнее. Это позволяет более разумно администрировать состав пакетов, причем на нескольких машинах одновременно.

И вообще это больше похоже на флуд. Пишу виртуальные пакеты не я один. Они и так есть в системе. Если считаете, что их разработчики безгрешны и проверяют такие зависимости недоступным мне образом, то я в этом сильно сомневаюсь.
Что предложите делать с самописным пакетом? Как же утверждение о запрете использования make&&make install.

Вообще запутался для кого этот дистрибутив?
Если make install нельзя, а ебильды не трожь.

(Ну вот и сам во флуд свалился. Просто хотел объяснить ситуацию)

To: krigstask
Попробовал DEPEND="${RDEPEND}". Не помогло.
Ставил основные пакеты без --oneshot. Но иногда (как и положено) пересобирал пакеты с этим флагом.

Цитата:Попробовал

Цитата:
Попробовал DEPEND="${RDEPEND}". Не помогло

Как попробовал-то? (-:Е
Переписал ебилд и перепоставил его?

Текстовый редактор vi имеет два режима работы: в первом он пищит, а во втором — всё портит.

именно так. Могу провести

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

Могу провести эксперимент глубже:
назовем установленный виртуальный ебилд 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.

Kevol написал(а): С чего это

Kevol написал(а):
С чего это написание своих ебилдов считается хаком? Тем более, что мне так удобнее. Это позволяет более разумно администрировать состав пакетов, причем на нескольких машинах одновременно.

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

Я пробую понять что именно ты делаеш, и пока что не понял. Для чего у тебя в системе нужен пучок виртуалов и метапакетов зависящих один от другого?
Создание пакетов это хорошо, вот только каких пакетов? virtual'ы встречаются достаточно редко.
Возможно, если ты обьясниш не умозрительными конструкциями высосанными из пальца, а реальными примерами - будет понятнее, во всяком случае мне.

Попытаюсь объяснить.

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

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

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

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

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

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

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

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

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

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

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

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

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

теперь всё стало ясно

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

а world можно каментировать сколько угодно - при запуске emerge он переписывается с нуля, и там ничего не остаётся левого.

Только вот при использовании

Только вот при использовании @сетов, все содержащиеся в них пакеты попадут в world, а при использовании метапакетов, только сам метапакет. Я ставил кеды 4 через сет, так потом замучился от них мир вычищать.

При установке сета в мир

При установке сета в мир попадает сет. При удалении сета ничего лишнего в мире не будет. Достаточно сделать emerge --depclean

Более того, и --depclean не

Более того, и --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

Текстовый редактор vi имеет два режима работы: в первом он пищит, а во втором — всё портит.

совершенно верно. ЗЫ. просто

совершенно верно.
ЗЫ. просто я сеты ручками удаляю из /var/lib/portage/world_sets а потом депклин делаю.

Я когда кеды устанавливал

Я когда кеды устанавливал через сет, то у меня в /var/lib/portage/world прописалось все пакеты из сета, разве так и должно быть?

нет

нет

Возникает такой вопрос: а

Возникает такой вопрос: а почему это виртуальный пакет, а не метапакет?

Думаю, надо писать на bugs.gentoo.org

Текстовый редактор vi имеет два режима работы: в первом он пищит, а во втором — всё портит.

Отличная инструкция как

Отличная инструкция как делать НЕ надо.
Варианты как делать можно:
1. Использовать portage-2.2 и sets. У меня, например, для kde-4.3 свой сет на основе того что в kde-testing есть, из которого выкинуто более половины не нужного. Отлично обновляется.
2. Самому писать метапакеты. Не оптимальный, но тоже вариант.
3. Таки старый, проверенный способ - управляя world-ом. Тут стоит помнить что:
1. Если вручную дописать в world какой-либо пакет, то при следующем emerge -uvDN world он со всеми зависимостями появится в системе.
2. Ели вручную что-либо из world удалить - оно просто перестанет обновляться. Однако при emerge --depclean все пакеты, которые прямо или косвенно (по зависимостям) не указаны в world и system будут удалены. (отсюда - быстрый способ получить чистую систему rm /var/lib/portage/world && emerge --depclean).

Как-то так.

Ах да, н и ледить таки за тем что, где и почем размаскировано, замаскировано и какие keywords используются (имхо, для десктопа ~arch оптимально, для сервера ~arch или arch)

dancingfire

dancingfire написал(а):
Отличная инструкция как делать НЕ надо.
Варианты как делать можно:
2. Самому писать метапакеты. Не оптимальный, но тоже вариант.

чем мой подход отличается от virtual/httpd-basic ?

>>чем мой подход отличается

>>чем мой подход отличается от virtual/httpd-basic

Ваш подход, в отличие от того же virtual/httpd-basic, нам посмотреть трудно. По причине отсутствия текста вашего ебилда. К тому же пример не особо корректен. virtual/httpd-basic необходим для установки какого нибудь (все равно какого) сервера хттп. Поскольку апач в списке первый - он и поставится.

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

ЗЫ
Судя по описанию проблемы, портеж отработалл весьма корректно.

В том то и дело, что не

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

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

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

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

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

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

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

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

А в чём проблема с

А в чём проблема с использованием сетов-то?
можно скопировать набор используемых сетов с одной машины на другую и всё.

Ну и портэдж таки отработал совершенно корректно.

не понимаю как. Объясните на

не понимаю как.
Объясните на пальцах тупому... ;)

Вот допустим есть у вас этот

Вот допустим есть у вас этот виртуальный пакет в котором нн-ый набор пакетов записаны.
вместо написания ебилда создаём файл в /etc/portage/sets назовём его myset
потом записываем туда аналогично по синтаксису как в world (можно использовать конкретную версию, слот или просто наименование пакета) необходимые пакеты.
далее emerge @myset - во первых myset появится в /var/lib/portage/world_sets ну и поставится/перемержиться всё что в сете.
копируем этот set на все нужные машины.

profit

что касается описанной ситуации с переходом пакета из stable в testing - портэдж при emerge -uvDN world не предлагал сделать downgrade этого пакета до стабильной версии? если не предлагал - с таким не встречался, либо, если не возможно сделать downgrade (нет версии в stable состоянии) он будет ругаться на этот пакет. других вариантов (если сам этот пакет реально есть в world-е или в ран-тайм зависимостях того, что есть в world-е быть просто не может.

по порядку. С сетом понятна

по порядку.

С сетом понятна логика и разумность использования, но что-то сомневаюсь, что это генту-вей в случае распространения на несколько машин. Что смущает - копирование и соответственно поддержка актуальности содержимого /etc/portage/всё_равно_что.
Гораздо логичнее было бы развернуть локальный оверлей и подсоединить туда все заинтересованные машины. Тогда необходимо администрировать именно эти пакеты, а остальные подтянутся, если они заинтересованы в проблемной области, которую описывает пакет.
Распространение сетов мне напоминает копирование на машины /etc/passdw на все машины группы для обеспечения синхронизации пользователей. Поддержание актуальности passwd - это чисто локальная задача. (надеюсь ассоциация понятна)

Ну не предлагает мне emerge решать какие-то проблемы.
Думаю, что этот пакет и не был stable. Просто для него потерялась запись в /etc/portage/package.keywords. Чем (отсутствием проблем у emerge) я и озадачен. Я не желаю, чтобы он за меня решал проблемы, мне необходимо знать, что у него они возникли.

Пакет на моё последнее обновление portage имеет единственное ~x86 ~amd64 замаскированное состояние.

Для конкретики предлагаю выполнить следующее
echo "net-p2p/btpd ~*">>/etc/portage/package.keywords
(ну или в файл, если у вас это каталог)
emerge -av btpd
теперь сотрите внесенную запись в /etc/portage/package.keywords
и выполните
emerge -avuDN world

У меня так - последнее не вызывает проблем для emerge

PS!!! Профиль системы должен быть стабильным!
Что очень важно. И что еще более досадно - на стабильном профиле находятся те, кто хочет хоть каких-то гарантий стабильности, но для них-то и уготованы проблемы.

Цитата:Для конкретики

Цитата:
Для конкретики предлагаю выполнить следующее
echo "net-p2p/btpd ~*">>/etc/portage/package.keywords
(ну или в файл, если у вас это каталог)
emerge -av btpd
теперь сотрите внесенную запись в /etc/portage/package.keywords
и выполните
emerge -avuDN world

Именно в таком варианте проверить не смогу, у меня ~x86, но если я размаскирую замаскированный ебилд, установлю, а потом удалю размаскировку - произойдёт либо даунгрейд (о чём будет указано в выводе портэджа), либо, если не куда даунгрейдится, то портэдж будет ругаться о том, что все пакеты, необходимые чтобы выполнить заданные условия замаскированы.

Цитата:
Распространение сетов мне напоминает копирование на машины /etc/passdw на все машины группы для обеспечения синхронизации пользователей. Поддержание актуальности passwd - это чисто локальная задача. (надеюсь ассоциация понятна)

Совершенно разные вещи.
sets - аналог мета пакетов, если у вас на 10 машинах нужен один и тот же набор приложений - то копирование (можно сделать одну директорию с сетами и монтировать её по nfs, если всё в одной сети, можно сделать свой оверлей, добавить сеты в него, так как для каждого оверлея могут быть свои сеты, и потом синхронизировать оверлей) это именно то что нужно. В конце-концов можно сделать не один сет со 100 пакетами а 10 с 10 в каждом, и, соответственно, где надо там определённые из этих 10 сетов - те там и устанавливать.

Цитата:
Думаю, что этот пакет и не был stable. Просто для него потерялась запись в /etc/portage/package.keywords. Чем (отсутствием проблем у emerge) я и озадачен. Я не желаю, чтобы он за меня решал проблемы, мне необходимо знать, что у него они возникли.

Ещё раз. Если была удалена размаскировка - либо доунгрейд, тогда портэдж ничего не скажет (кроме того что сообщит о самом факте доунгрейда). либо внимательно читаем весь вывод сгенерированный портэджом.

Kevol написал(а): С сетом

Kevol написал(а):
С сетом понятна логика и разумность использования, но что-то сомневаюсь, что это генту-вей в случае распространения на несколько машин. Что смущает - копирование и соответственно поддержка актуальности содержимого /etc/portage/всё_равно_что.
Гораздо логичнее было бы развернуть локальный оверлей и подсоединить туда все заинтересованные машины. Тогда необходимо администрировать именно эти пакеты, а остальные подтянутся, если они заинтересованы в проблемной области, которую описывает пакет.

sets это как раз более gentoo-way чем лепнина из виртуалов. Сеты можно подключать прямо из оверлея, и многие оверлеи так делают, как один из примеров могу привести
https://projects.niifaq.ru/projects/enlightenment/repository/entry/sets.conf
тока он (сайт) подтормаживает. вечером узнаю где описано понормальному.

в kde-testing тоже есть свои

в kde-testing тоже есть свои сеты.

Проверил внесение пакета в

Проверил внесение пакета в world
emerge -avuDN world : полное молчание
emerge -ave world : сознался что не может установить замаскированный пакет
emerge -pv --depclean : не упомянул, что существуют какие-то проблемы

первое улыбнуло - не каждый будет на досуге пересобирать мир ;)

Цитата: cadence ~ # eix q7z *

Цитата:
cadence ~ # eix q7z
* app-arch/q7z
Available versions: (~)0.7.1
Homepage: http://k7z.sourceforge.net/7Z/Q7Z/
Description: A GUI frontend for p7zip
cadence ~ # echo "app-arch/q7z" >> /var/lib/portage/world
cadence ~ # ACCEPT_KEYWORDS="-~x86 x86" emerge -upvDN world

Кучка ругательств, ибо у меня ~x86 по дефолту

!!! Problems have been detected with your world file
!!! Please run emaint --check world

!!! Ebuilds for the following packages are either all
!!! masked or don't exist:
app-arch/q7z

cadence ~ # emerge -upvDN world

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild U ] kde-base/plasma-apps-4.2.85 [4.2.71] USE="-debug -kdeprefix" 0 kB [1]
[ebuild U ] kde-base/kdeartwork-kscreensaver-4.2.85 [4.2.71] USE="eigen opengl xscreensaver -debug -kdeprefix" 0 kB [1]
[ebuild U ] kde-base/kdeplasma-addons-4.2.85 [4.2.71] USE="desktopglobe exif opengl semantic-desktop -debug -kdeprefix" 0 kB [1]
[ebuild N ] app-arch/q7z-0.7.1 175 kB [0]
[ebuild N ] x11-misc/2gis3-2009.05 0 kB [2]

Total: 5 packages (3 upgrades, 2 new), Size of downloads: 175 kB
Portage tree and overlays:
[0] /home/gentoo/portage
[1] /usr/local/portage/layman/kde-testing
[2] /home/gentoo/overlay

что я делаю не так?

Kevol написал(а):Проверил

Kevol написал(а):
Проверил внесение пакета в world
emerge -avuDN world : полное молчание

дык вы указали emerge -uN , тк нету ни новых USE ни более новых версий всё и молчит, вот если emerge -av world

Говорят, что Йа такое-же быдло как и все, господа хорошие, для системы ценностей большинства людей йА зНаЧиТеЛьНо хУже!(с) mr.Freeman

>>То что мне тут объясняют,

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

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

Меня удивляет метод решения.
Прописать скрипт типа
emerge ... p1 p2 p3 p4 .. pn и обозвать его списком много проще,чем возиться с чужой системой, коей для вас является портеж

Начались нравоучения.

Я описываю баг emerge. Описываю его на примере.
Мой подход в администрировании систем вторичен в данном контексте. Хороши ли сеты, и на сколько плохо составлять собственный оверлей предлагаю оставить в стороне.

Проблема в следующем. Доверие к emerge.

Мои наблюдения.

Есть пакет A. Он замаскирован. Причем полностью.
От него зависит пакет В. (Пускай тоже будет замаскирован)
Для установки B размаскируем А и B.
Пользуемся.
В ходе фатального редактирования конфигов теряем размаскировку А.
emerge теряет из видимости пакет А.

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

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


>emerge ... p1 p2 p3 p4 .. pn и обозвать его списком много проще
Было бы проще, сидел бы спокойно и не искал бы решений в самописных пакетах.

PS. Многие вступившие в полемику даже не имеют возможности проверить мною высказанное, так как находятся на тестовой ветви. А там априори, данной проблемы возникнуть не может.

Ересь

В чем проблема то? Вы удалили кейворд /etc/portage/package.keywords (сам он удалится не мог). Учитывая, что вы ставите с -1, возможно и в оригинале он был поставлен как зависимость или через -1 - в world его нет, в депендансах его тоже, видимо нет - не зря же он жестко замаскирован. А портаж вполне обоснованно отказывается ставить пакет без кейвордов.

Более того, скажу вам - очень может оказатся так, что если вы давно не обновляли систему, ебилдов для половины существующих пакето-версий уже не будет. Но портаж хранит ебилд в /var/db, так что ничего страшного тут нет.

Не стоит слишком сильно использовать -1, и смотреть перед --depclean на -p --depclean (это в man'е даже написано), в случае отсутсвия пакета в world'е (пакеты могут и выпасть из world'а, ввиду каких-нибудь ошибок portage, особенно это было часто при миграции с portage-2.1 на начальные rc 2.2 - от ошибок никто не застрахован, так что надо проверять и перепроверять) - emerge --noreplace <package>.

А так - вы сами себе злобный буратино, и что это - "инструкция" мне непонятно. Под такой топик подходит скорее rm -Rf /var/db

P.S. А "администрирование" виртуальными пакетами - это хирургическая операция бинзопилой. Если вы хотите, чтобы менджер пакетов самостоятельно разбирался со всей той дурью которую может понаделать пользователь - то это делают msi в винде и apt-get в убунте. Намек понятен?

eix-test-obsolete

eix-test-obsolete

Black Shadow

Black Shadow написал(а):
eix-test-obsolete

Спасибо. Вот это уже что-то интересное. Надо проверить на подопытном.

Настройки просмотра комментариев

Выберите нужный метод показа комментариев и нажмите "Сохранить установки".