Удаление пакетов c зависимостями в gentoo

Уж сколько раз удалял разного калибра пакеты по emerge -C - никогда с таким не сталкивался. Что-то у тебя, походу, при установке в своё время дурило.

findcruft тебя спасёт.

# eix -I findcruft
[I] app-admin/findcruft2
     Available versions:  20080831[1] 20080831[2]
     Installed versions:  20080831[1](09:24:01 05.10.2009)
     Homepage:            http://benedikt.boehm.name
     Description:         findcruft2 is a tool to find orphaned files for unmerged packages

[1] "local" /usr/local/portage
[2] "hollow" /usr/local/overlays/layman/hollow

emerge --depclean ?
Хотя соглашусь, что не должно быть этого

На примере the GIMP

equery -q d gimp # какие установленные пакеты зависят от gimp который мы собрались удалять

emerge gimp --unmerge #удалили

emerge --depclean #почистили систему от ненужного мусора

А правильнее при установке чего то с тучей зависимостей сделать таким макаром emerge gimp -pv из всего выхлопа делаем set @gimp об этом читать тут а в последствие установка всего и со всеми зависимостями emerge @gimp удаление всего и со всеми зависимостями emerge @gimp --unmerge обновление всего и со всеми зависимостями emerge --update --newuse --deep @gimp

Костылевато звучит. Да и в случае с гимпом в этот сет попадут куча пакетов навроде glib, gtk+, zlib и т.д. Как ты думаешь что произойдёт после удаления такого сета? Сеты не отслеживают обратные зависимости и не предназначены вобще они для этого.

Костылевато звучит.

Да нет уважаемый Nao «куча пакетов навроде glib, gtk+, zlib и т.д.» уже будет в системе так как вменяемые люди gimp обычно ставят не на голый stage-3 а на систему с уже с установленными как минимум xorg и gnome/kde/{или что там больше по душе}.

Ди и вам для справки sys-libs/zlib, dev-libs/glib идут еще в stage-3 а gtk+ подтянется на этапе установки любого dm/wm без которых смысла в the gimp тоже как бы мало...

Как ты думаешь что произойдёт после удаления такого сета?

А произойдет то что должно произойти. Удалится все что попало в сет. Но орган под названием мозг для того и дан человеку чтобы хоть иногда думать... И если человек в сет gimp добавит glib, gtk+, zlib а потом сделает emerge --unmerge @gimp то это ссзб

> Да нет уважаемый Nao "куча пакетов навроде glib, gtk+, zlib и т.д." уже будет в системе так как вменяемые люди gimp обычно ставят не на голый stage-3 а на систему с уже с установленными как минимум xorg и gnome/kde/{или что там больше по душе}.

Может будет, а может и не будет. У юзера например может стоять не gtk WM/DE и он захочет поставить гимп. В тот "сет" вполне вероятно попадёт пакет dev-python/pygtk и если в дальнейшем будут установлены другие гтк приложения которые его используют, а потом юзер сделает emerge -C @gimp, то будет не очень хорошо.
Напротив - emerge --depclean хоть и не самый удачный инструмент, но он отработает такую ситуацию корректно.

>А произойдет то что должно произойти. Удалится все что попало в сет. Но орган под названием мозг для того и дан человеку чтобы хоть иногда думать... И если человек в сет gimp добавит glib, gtk+, zlib а потом сделает emerge --unmerge @gimp то это ссзб

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

Я не говорю что использовать сеты для хранения зависимостей (которые кстати ещё могут и поменяться!) нельзя, но это не удобно и создаёт массу потенциальных проблем в будущем.

Nao возьмем гипотетический пример в вакууме. Человек определился с USE флагами и не собирается их менять через каждые пять минут. Человек ставит «нечто» с кучей зависимостей. При условии неизменности USE флагов в сет «@нечто» попадет все её зависимости. Так вот в данном случае удаление emerge @нечто --unmerge не создаст никаких проблем и система после удаления вернется к состоянию до установки «нечто» с кучей зависимостей.

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

Все минусы сполна компенсируются плюсами.

> Человек определился с USE флагами и не собирается их менять
Флаги могут измениться после установки/удаления некоторых пакетов сами(редко)
Флаги в новом EAPI могут сами являться зависимостями и соответственно меняться на определённых пакетах самостоятельно.

> Так вот в данном случае удаление emerge @нечто --unmerge не создаст никаких проблем
Это подходит только для варианта - поставил, посмотрел, удалил. Если после "поставил" были поставлено много других пакетов, то см. мой пост выше.
(Кстати для "поставил, посмотрел, удалил" я использую demerge)

> К тому же человек сразу же получает дополнительные плюшки в виде возможности отследить зависимостью от чего встал тот или иной пакет.
qdepends -Q покажет все обратные зависимости пакета

> Не вопрос обновить только "нечто" с его зависимостями не трогая всего остального.
А в чём отличие от emerge -uD package или emerge -u package ?

>При условии использования бинарников не вопрос установить "нечто" одним движением руки после удаления.
Не совсем понял мысль. В чём будет разница с emerge -k package?

Флаги могут измениться после установки/удаления некоторых пакетов сами(редко)

Флаги в новом EAPI могут сами являться зависимостями и соответственно меняться на определённых пакетах самостоятельно.

Угу ВНЕЗАПНО все что угодно может произойти это да. И конец света тоже может быть ВНЕЗАПНО...

Не вопрос обновить только «нечто» с его зависимостями не трогая всего остального.

А в чём отличие от emerge -uD package или emerge -u package ?

Сравни к примеру emerge -uD @gnome с тем что предлагаешь ты. У меня одной командой emerge -uD @gnome обновится исключительно гном со всеми своими зависимостями и не трогая всего остального @world @system.

Угу ВНЕЗАПНО все что угодно может произойти это да. И конец света тоже может быть ВНЕЗАПНО...

Давай не будем уходить от темы и обсуждать в тематическом разделе конец света. Вероятность пересборки пакета из-за зависимости от юзфлага на пакете не так уж и мала. По моим очень приблизительным подсчётам в портежах примерно 5% пакетов с такими зависимостями.

Кстати вот они, красавцы (приблизительно):

qgrep -He '.*/.*\[.\?[a-z0-9-]*\.\?]'

Сравни к примеру emerge -uD @gnome с тем что предлагаешь ты.

В сабже был гимп, а о гноме я ничего не говорил. Сэты и задумывались как замена метапакетам(таким как гном).

У меня одной командой emerge -uD @gnome обновится исключительно гном со всеми своими зависимостями и не трогая всего остального @world @system.

ну emerge -uD gnome сделает тоже самое, при условии что стоят все пакеты которые тянет метапакет gnome-base/gnome.

Различие появляется когда хочется не ставить некоторые пакеты из метапакета gnome (или хочется добавить своё).

В случае Гимпа - всё равно придётся ставить все его зависимости (а ненужные можно отрубить USE-флагами), следовательно заводить сет не имеет смысла.

Кстати, возвращаясь к вопросу ТС: создание сета никак бы не повлияло на ошибку при revdep-rebuild.

По видимому это недоработка в пакете гимпа или какаято ошибка которую совершил сам ТС (ничего конкретного не приходит на ум), либо глюк portage =)

В таком случае уже выше написали про findcruft.

Вероятность пересборки пакета из-за зависимости от юзфлага на пакете не так уж и мала.

Вероятность того что пакет просто удалят/переименуют тоже есть и она не меньше вероятности изменений в USE флагах...

В сабже был гимп, а о гноме я ничего не говорил. Сэты и задумывались как замена метапакетам(таким как гном).

Эээ Nao как ты там говорил «Давай не будем уходить от темы» да? Nao еще раз по буквам - the GIMP он что на чистый stage-3 будет ставить и все исключительно только ради the GIMP и кроме the GIMP там не будет ни одного DM/WM ? Да если он таки не с марса то у него к моменту установки the GIMP уже будет по крайней мере stage-3 + xorg + DM/WM и твои претензии

Да и в случае с гимпом в этот сет попадут куча пакетов навроде glib, gtk+, zlib и т.д.

беспочвенны. Поскольку ежели у него к моменту установки the GIMP уже будет stage-3 + xorg + DM/WM то sys-libs/zlib и dev-libs/glib физически не смогут попасть в сет @gimp поскольку они идут еще в stage-3 и их нет необходимости устанавливать при сборке the GIMP на системе в которой они уже и так есть еще со stage-3... А что касается gtk+ так оно либо подтянется зависимостью на этапе установки DM/WM если ставился gnome иначе если ставился KDE и ничему до установки the GIMP не потребовалось gtk+ ну да попадет в этом случае gtk+ в сет @gimp И ЧТО? Таким же образом во втором случае (у человека кеды и gtk+ ничему не була нужна до установки the GIMP) и без сетов при удалении gimp через emerge gimp --unmerge библиотека gtk+ слетит после первого же emerge --depclean.

Вероятность того что пакет просто удалят/переименуют тоже есть и она не меньше вероятности изменений в USE флагах...

Согласен. Но это аргумент не в пользу использования сетов в таких целях, а как раз против.

Поскольку ежели у него к моменту установки the GIMP уже будет stage-3 + xorg + DM/WM то sys-libs/zlib и dev-libs/glib физически не смогут попасть в сет @gimp поскольку они идут еще в stage-3 и их нет необходимости устанавливать при сборке the GIMP на системе в которой они уже и так есть еще со stage-3...

Насчёт zlib и glib я погорячился. С этим я согласен.

иначе если ставился KDE и ничему до установки the GIMP не потребовалось gtk+ ну да попадет в этом случае gtk+ в сет @gimp И ЧТО? Таким же образом во втором случае (у человека кеды и gtk+ ничему не була нужна до установки the GIMP) и без сетов при удалении gimp через emerge gimp --unmerge библиотека gtk+ слетит после первого же emerge --depclean.

Я повторю ещё раз, видимо я выше изложил свою мысль непонятно:

Представим такую ситуацию: у юзера стоит KDE или другая не gtk WM/DE, пакет gtk+ не стоит. Он хочет поставить gimp.

В случае с сетам юзер:

1. Составляет сет из зависимостей которые тянет gimp (туда в т.ч. входит gtk+) + сам gimp
2. Устанавливает сет @gimp
3. Устанавливает любую gtk программу (у которой в зависимостях соответственно gtk+). Пусть это будет например gajim
4. Удаляет сет @gimp. Он думает что удалятся только ненужные зависимости, наивный парнишка... С сетом гимпа уходит пакет gtk+
5. Плачет над нерабочим gajim`ом и пытается понять в чём проблема.

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

В классическом случае:

1. Просто делает emerge gimp
2. Устанавливает gajim, да хоть весь гном.
3. Удаляет gimp обычным способом emerge -C gimp
4. Ждёт удобное юзеру кол-во времени (не ограничено)
5. Обновляет мир.
6. Делает emerge --depclean -a

Причём в списке, который выводит depclean юзеру придётся обратить внимание только на пакеты которые он установил сам, используя --oneshot, а на всякие зависимые библиотеки, которые юзер может и не помнить зачем они нужны в системе, можно и не смотреть.

Хотя у depclean минус в том что надо обновить мир перед его использованием, это компенсируется тем, что будут учтены все нужные по зависимостям пакеты и его(depclean) можно отложить на сколь угодно долгое время. А «лишние пакеты» в системе особо не мешают и могут подождать до обновления мира.

Я согласен что метод с сетами подходит для варианта «поставил, посмотрел, удалил» и тут он беcспорно лучше чем depclean. Но если между событиями «поставил» и «удалил» ожидается большой промежуток времени, то имхо этот метод не подходит и может привести к удалению нужных пакетов в системе.

Можно конечно самому следить за библиотеками, которые входят в наш сет @нечто и перед удалением сета смотреть, «а не нужны ли все эти зависимости кому-то ещё?», т.е. подрабатывать пакетным менеджером. Зачем?

> emerge @gimp --unmerge

Я думаю, это бред.

Допустим, есть два нужных мне пакета A и B, обоим нужна хитрая либа C. Я ставлю пакет A, делаю сет @A = (A, C). Потом ставлю B (C уже поставлен). Потом удаляю A...

Проще удалять ненужные пакеты из world, а потом делать depclean. Хоть и немного странный алгоритм, но зато работает железобетонно.

У обоих вариантов есть свои плюсы и у обоих вариантов есть свои минусы. Но если portage предоставляет такую возможность то там где это действительно нужно не использовать её глупо! И да случаев поставить на посмотреть бывает тоже немало. А обо всем остальном - голова человеку на то и дана чтобы думать. А в gentoo это проявляется еще сильнее.

> Я думаю, это бред.

Я об этом же написал постом выше, только многабуков у меня получилось.