История изменений

это было так трудно сделать - парсинг списка зависимостей метапакета и их удаление.
о всех остальных ПМ удаление пакета с его зависимостями - базовый функционал. Но только не в portage, да.

и сломать системы всем пользователям в случае ошибки алгоритма, ага. Необходимо сначала протестировать такое решение. Вдобавок сущности хоть и похоже, но кардинально отличаются направленностью. Сеты более правильны для пользователя, ИМХО. Ты не понимаешь, в source-based дистрибутиве с зависимостями все гораздо гибче(и сложнее) чем в binary-based. Почитай хотя бы про automagic dependencies(это не относится непосредственно к теме беседы, но дает забавную пищу для размышлений).

....Это типа тоже круто и так и должно быть?

Да. Потому что сделав «emerge -C библиотека»(пусть пакет который ты удалил будет библиотекой, для простоты размышлений) ты привел дерево пакетов в неконсистентное состояние. Это как с системами контроля версий - ты внес изменения, но не зафиксировал(commit) их. На самом деле - полезно для некоторых экспериментов. Для приведения дерева в консистентное состояние у тебя есть несколько вариантов:

1) revdep-rebuild

2) emerge @preserved-rebuild (Требуется portage 2.2)

Область применения п. 2 немного другая, возможно при этом будут лишние действия, но учитывая что требуешь ты(ОБЯЗАТЕЛЬНОЕ удаления пакетов, которые зависят от удаленного вручную) - это тебя не должно смутить.

Пример того момента, где такое поведение будет оправдано: предположим есть куча пакетов, зависящих от virtual/editor(взял для примера). Удаление, допустим, единственного редактора в системе(nano), по твоей логике должно вызвать автоматическое удаление этих пакетов(пусть их будет 200, скажем). А я ПРОСТО хочу заменить редактор по умолчанию, сначала удалив старый(nano), затем поставив другой(ну, может мне vi или emacs больше нравится).

Поведения в твоем случае приведет к тому, что 200 пакетов надо будет переустановить заново(введя их имена вручную или отследив их через emerge.log). Portage ИМХО поступает правильно, давая свободу пользователю в любых действих с пакетами. Можно удалить nano и засунуть его в package.provided. Можно удалить nano, поставить vi и зависимость от virtual/editor переключится на него сама.

И да, если тебе не нравится portage, в генте с недавних времен можно использовать альтернативные пакетные менеджеры - pkgcore и paludis. Я их не щупал, ибо меня всё устраивает

это было так трудно сделать - парсинг списка зависимостей метапакета и их удаление.
о всех остальных ПМ удаление пакета с его зависимостями - базовый функционал. Но только не в portage, да.

и сломать системы всем пользователям в случае ошибки алгоритма, ага. Необходимо сначала протестировать такое решение. Вдобавок сущности хоть и похоже, но кардинально отличаются направленностью. Сеты более правильны для пользователя, ИМХО. Ты не понимаешь, в source-based дистрибутиве с зависимостями все гораздо гибче(и сложнее) чем в binary-based. Почитай хотя бы про automagic problem(это не относится непосредственно к теме беседы, но дает забавную пищу для размышлений).

....Это типа тоже круто и так и должно быть?

Да. Потому что сделав «emerge -C библиотека»(пусть пакет который ты удалил будет библиотекой, для простоты размышлений) ты привел дерево пакетов в неконсистентное состояние. Это как с системами контроля версий - ты внес изменения, но не зафиксировал(commit) их. На самом деле - полезно для некоторых экспериментов. Для приведения дерева в консистентное состояние у тебя есть несколько вариантов:

1) revdep-rebuild

2) emerge @preserved-rebuild (Требуется portage 2.2)

Область применения п. 2 немного другая, возможно при этом будут лишние действия, но учитывая что требуешь ты(ОБЯЗАТЕЛЬНОЕ удаления пакетов, которые зависят от удаленного вручную) - это тебя не должно смутить.

Пример того момента, где такое поведение будет оправдано: предположим есть куча пакетов, зависящих от virtual/editor(взял для примера). Удаление, допустим, единственного редактора в системе(nano), по твоей логике должно вызвать автоматическое удаление этих пакетов(пусть их будет 200, скажем). А я ПРОСТО хочу заменить редактор по умолчанию, сначала удалив старый(nano), затем поставив другой(ну, может мне vi или emacs больше нравится).

Поведения в твоем случае приведет к тому, что 200 пакетов надо будет переустановить заново(введя их имена вручную или отследив их через emerge.log). Portage ИМХО поступает правильно, давая свободу пользователю в любых действих с пакетами. Можно удалить nano и засунуть его в package.provided. Можно удалить nano, поставить vi и зависимость от virtual/editor переключится на него сама.

И да, если тебе не нравится portage, в генте с недавних времен можно использовать альтернативные пакетные менеджеры - pkgcore и paludis. Я их не щупал, ибо меня всё устраивает

это было так трудно сделать - парсинг списка зависимостей метапакета и их удаление.
о всех остальных ПМ удаление пакета с его зависимостями - базовый функционал. Но только не в portage, да.

и сломать системы всем пользователям в случае ошибки алгоритма, ага. Необходимо сначала протестировать такое решение. Вдобавок сущности хоть и похоже, но кардинально отличаются направленностью. Сеты более правильны для пользователя, ИМХО. Ты не понимаешь, в source-based дистрибутиве с зависимостями все гораздо гибче(и сложнее) чем в binary-based. Почитай хотя бы про automagic problem(это не относится непосредственно к теме беседы, но дает забавную пищу для размышлений).

....Это типа тоже круто и так и должно быть?

Да. Потому что сделав «emerge -C библиотека»(пусть пакет который ты удалил будет библиотекой, для простоты размышлений) ты привел дерево пакетов в неконсистентное состояние. Это как с системами контроля версий - ты внес изменения, но не зафиксировал(commit) их. На самом деле - полезно для некоторых экспериментов. Для приведения дерева в консистентное состояние у тебя есть несколько вариантов:

1) revdep-rebuild 2) emerge @preserved-rebuild (Требуется portage 2.2)

Область применения п. 2 немного другая, возможно при этом будут лишние действия, но учитывая что требуешь ты(ОБЯЗАТЕЛЬНОЕ удаления пакетов, которые зависят от удаленного вручную) - это тебя не должно смутить.

Пример того момента, где такое поведение будет оправдано: предположим есть куча пакетов, зависящих от virtual/editor(взял для примера). Удаление, допустим, единственного редактора в системе(nano), по твоей логике должно вызвать автоматическое удаление этих пакетов(пусть их будет 200, скажем). А я ПРОСТО хочу заменить редактор по умолчанию, сначала удалив старый(nano), затем поставив другой(ну, может мне vi или emacs больше нравится).

Поведения в твоем случае приведет к тому, что 200 пакетов надо будет переустановить заново(введя их имена вручную или отследив их через emerge.log). Portage ИМХО поступает правильно, давая свободу пользователю в любых действих с пакетами. Можно удалить nano и засунуть его в package.provided. Можно удалить nano, поставить vi и зависимость от virtual/editor переключится на него сама.

И да, если тебе не нравится portage, в генте с недавних времен можно использовать альтернативные пакетные менеджеры - pkgcore и paludis. Я их не щупал, ибо меня всё устраивает