Gentoo, удаление пакета и всего, что от него зависит

То есть, допустим, я сношу GTK и у меня удаляются все GTK-проги.

# cat unmerge-all.sh

#!/bin/sh
emerge -C $1
emerge --depclean $1

Использовать: ./unmerge-all.sh package

Проверки на корректность введенных атомов - вставить по вкусу

Либо emerge -C <пяпя>; emerge --depclean либо осилить таки уже эти сраные сэты и сделать emerge -С @пяпя

Pinkbyte, init_6, да что вы все одно и то же то говорите? Так я снесу пакет и Depends, а мне надо снести пакет и Reverse Depends. Вот, специально выполнил - http://paste.debian.net/plainh/48bdc4ee. Это совсем не то, что надо.

Вот, специально выполнил - http://paste.debian.net/plainh/48bdc4ee. Это совсем не то, что надо.

Ты делал emerge -C gtk+:2; emerge -c а тебе что говорили сделать? найди десять отличий.

Это я и сделал. -c эквивалентен --depclean, даже специально ещё раз проверил. Или ты о чём-то ещё?

Это я и сделал. -c эквивалентен --depclean, даже специально ещё раз проверил. Или ты о чём-то ещё?

Вон прочитай http://www.gentoo-wiki.info/HOWTO_remove_KDE как раз твой случай.

И да дерево рубят у корня. Но у большого дерева сперва отпиливают ветки а затем рубят у корня. Тут так-же сперва удаляются всё пакеты которые зависят от gtk+:2 в твоём случае… а затем удаляется сама библиотека.

emerge -c <пакет>

Так я снесу пакет и Depends, а мне надо снести пакет и Reverse Depends.

Так ты снесешь и всего его reverse depends. Кури ман дальше.

То что у тебя битое дерево зависимостей еще ДО удаления gtk - это твои проблемы

можно редактировать world и делать emerge -c, а можно и не делать, есть они не просят, места на диске хватает, проблем нет. Я к этому тоже не сразу пришел.

только что проверил:

>emerge -C net-libs/tox
#удалилось
>emerge --depclean net-libs/tox
--- Couldn't find 'net-libs/tox' to depclean.
>>> No packages selected for removal by depclean

у меня если что стоит куча клиентов токса, которые зависят от net-libs/tox

тот же эксперимент с токсом:

>emerge --depclean

 * 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 <atom>`.  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.

Calculating dependencies                               ... done!
 * Dependencies could not be completely resolved due to
 * the following required packages not being installed:
 * 
 *   net-libs/tox pulled in by:
 *     net-im/toxic-9999
 * 
 *   net-libs/tox pulled in by:
 *     net-im/utox-9999
 * 
 *   net-libs/tox pulled in by:
 *     net-im/venom-9999
 * 
 * Have you forgotten to do a complete update prior to depclean? The
 * most comprehensive command for this purpose is as follows:
 * 
 *   emerge --update --newuse --deep --with-bdeps=y @world
 * 
 * Note that the --with-bdeps=y option is not required in many
 * situations. Refer to the emerge manual page (run `man emerge`)
 * for more information about --with-bdeps.
 * 
 * Also, note that it may be necessary to manually uninstall
 * packages that no longer exist in the portage tree, since it may
 * not be possible to satisfy their dependencies.

eternal_sorrow ну вот и кто тебе виноват что у тебя и net-libs/tox и net-im/toxic-9999, net-im/utox-9999, net-im/venom-9999 всё запихнуто в world?

Примите уже разупорин и сходите почитайте man portage а в нём обратите особое внимание на разницу между emerge -1 пяпя и emerge пяпя

сходите почитайте man portage

чукча не читатель, чукча писатель

Вот смотри у тебя всё это net-libs/tox, net-im/toxic-9999, net-im/utox-9999, net-im/venom-9999 запихнуто в мир причем всё зависит от net-libs/tox. Ты делаешь emerge -C net-libs/tox и портежи удаляют то что им приказано. Однако всё остальное net-im/toxic-9999, net-im/utox-9999, net-im/venom-9999 при этом никуда из мира не девается. Оно как там было так и остается. И при любой следующей операции портеж видит в мире кучу потрохов без нужной им зависимости - вывод вернуть зависимость на её законное место до любых последующих действий.

И это безупречная логика потому что всё в мире обязано иметь зависимости. И ни один идиот никогда не впихнет {зависимости/библиотеки} в мир. В мире должны быть программы а не {зависимости/библиотеки}. А мир с программами без нужных им зависимостей это поломанный мир и его нужно немедленно чинить.

ну вот и кто тебе виноват что у тебя и net-libs/tox и net-im/toxic-9999, net-im/utox-9999, net-im/venom-9999 всё запихнуто в world?

net-libs/tox нету в world, остальные три есть. А разве их не должно там быть? Они там по той же причине, почему там например находится www-client/chromium. что такое --oneshot знаю и применяю когда нужно (например чтобы поставить net-libs/tox обратно после того как снес ее для эксперимента).

net-libs/tox нету в world, остальные три есть. А разве их не должно там быть? Они там по той же причине, почему там например находится www-client/chromium. что такое --oneshot знаю и применяю когда нужно (например чтобы поставить net-libs/tox обратно после того как снес ее для эксперимента).

Если б знал не страдал бы ерундой… Удаляется сперва всё из мира что зависит от net-libs/tox а затем сама net-libs/tox. Так и только так. И ссылка http://www.gentoo-wiki.info/HOWTO_remove_KDE со мной согласна. В твоем случае это emerge -C =net-im/toxic-9999 =net-im/utox-9999 =net-im/venom-9999 а потом emerge --depclean и вот уже на этой операции, если „мудрый“ ты не впихнул и её в мир, net-libs/tox отправится к праотцам.

Это всё очевидные вещи, но ТС спрашивает про другое. Как не зная заранее, какие пакеты зависят от net-libs/tox снести её вместе со всеми этими пакетами. Pinkbyte предложил для этого свой скрипт, я своим экспериментом продемонстрировал, что этот скрипт не выполняет этой задачи.

Это всё очевидные вещи

Да неужели? Оно и видно вообще то…

Как не зная заранее, какие пакеты зависят от net-libs/tox снести её вместе со всеми этими пакетами.

Ну давай посмотрим… А как же в gentoo узнать всё что зависит от заданного пакета? Наверное сперва надо мозг включить а потом equery depends посмотреть да? Но потом всё ж равно нужно делать то же самое что было сказано в первом же сообщении!!!

я своим экспериментом продемонстрировал, что этот скрипт не выполняет этой задачи

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

Но portage-teem с радостью примет твои патчи если ты сумеешь исправить этот досадный недостаток.

ОМФГ, неужели я правда произвожу впечатление полного кретина? Я все это понимаю. И про equery depends знаю. Но это всё ручная работа, которая может быть гораздо менее тривиальной если дерево обратных зависимостей сложнее моего простого случая. apt-get например очень неплохо заруливает такую ситуацию, предлагая подчистить пакет вместе с деревом обратных зависимостей. Было бы неплохо иметь такую вещь и в gentoo. И жаль, что ее нет. Вот о чем говорит ТС. Когда я переходил с ubuntu на gentoo, этот маленький недостаток portage был весьма неприятен. Теперь конечно привык, к тому же его преимущества с лихвой окупают недостатки.

Примите уже разупорин и сходите почитайте man portage а в нём обратите особое внимание на разницу между emerge -1 пяпя и emerge пяпя

мегабакса напоминаешь :)

но все правильно пишешь, да

Вот о чем говорит ТС.

ТС неосилил разницы между emerge -1 пяпя и emerge пяпя.

Когда я переходил с ubuntu на gentoo, этот маленький недостаток portage был весьма неприятен.

У portage есть логика. И даже здесь portage все делает правильно потому что программы в world-е потеряли зависимость и ему насрать на то что именно ты там на самом деле хотел с ними делать однако до тех пор пока они в «мире» у них должны быть исправные зависимости.

То что ты пытаешься показать как «недостаток» наглядно иллюстрируется другим примером - чтобы избавится от большого дерева сперва обрубают ему все ветки затем рубят ствол у основания и только в конце по прошествии времени корчуют пенек вместо всего этого ты с топором в руках долбишь землю около корня дерева со словами «ну оно же не работает…»

Pinkbyte в первом же сообщении всё написал правильно. Дальше никого не волнует… и если ты хочешь долбить землю топором около корня доказывая всем что «оно не работает» вместо того чтобы срубить ветки затем ствол и избавится от пня то так тому и быть и никто не станет тебя останавливать. portage именно так и поступил.

emerge --deselect всё это из world-файла, потом повторить. world-файл portage стремится сохранить в любом случае, консистентность дерева превыше всего.

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

Парси emerge --depgraph, делов-то.

И жаль, что ее нет.

«Если чего-то в Opensource нет - это потому что ТЫ этого не написал» (с) забыл_кто

А по теме - есть что-то из парсеров vdb(то ли из gentoolkit, то ли из portage-utils), что позволит решить данную задачу проще и быстрее, чем комбинация sed/grep/awk над выхлопом portage, но я сейчас реально не могу это припомнить, потому что дико хочу спать.

Так что - может завтра...

Дальше никого не волнует… и если ты хочешь долбить землю топором около корня доказывая всем что «оно не работает» вместо того чтобы срубить ветки затем ствол и избавится от пня то так тому и быть и никто не станет тебя останавливать. portage именно так и поступил.

Ну на самом деле логика тут такова(если у нас нет ничего кроме emerge, ни eix, ни qfile, нихрена, только base-system, только хардкор):

1) доставаем broken deps; 2) грохаем их;

Пункт 1 осуществляется парсингом выхлопа emerge(кстати там ЕМНИП есть ключ для более удобоваримого для автоматического парсинга выхлопа).

Пункт 2 - либо emerge -C @preserved-rebuild(это сработает только для либ, поэтому не годится в общем случае), либо - удаляем полученное в пункте 1 из world file путём emerge --deselect и делаем emerge --depclean

Если остались еще зависимости - повторить с пункта 1, пока --depclean не сработает.

Но это - чистой воды велосипед, лучше почитать man по portage-utils и man по gentoolkit

Я так чуть верификатор чексумм установленных пакетов не написал, опираясь на данные из vdb. Слава Богу хватило ума почитать man qcheck и не пилить велосипед.

Еще как вариант свелосипедить(при наличии portage-utils/gentoolkit) - берем reverse depgraph от удаляемого пакета перед удалением(equery d например) и рекурсивно последовательно удаляем все revdeps по графу. Потом заглянцовываем это --depclean.

Это если совсем лениво читать ман...

На мой взгляд то как работает portage даже более правильно потому что если б был бы вундер-параметр у portage позволяющий «грохать вот это и дальше всё что от него зависит» можно было бы огрести кучу проблем просто от опечатки в результате действий к примеру с libc, glibc… :)

Кстати, желающим user-friendly опции в самом пакетном менеджере - она есть в paludis. --with-unused-deps кажется, если мне не изменяет память.

чтобы избавится от большого дерева сперва обрубают ему все ветки

Хотел бы я на это посмотреть. Что то мне подсказывает, что это даже чисто технически сложновато осуществить. Впрочем при валке особо крупного леса я никогда не присутствовал, поэтому спорить не буду. К тому же это оффтоп.

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

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

Если б оно было очевидно ты б не начал эксперименты ни о чем.

как ты беспалевно скора заработал