«При удалении AmaroK»: пол-KDE установилось вместе с ним, не желаете удалить эти пакеты тоже?

Это можно сделать только в CRUX. Имею в виду, простыми средствами. После команды: «prt-get depinst nameport», установщик кидает в консоль, какие пакеты были установлены дополнительно. Никто не мешает создать shell-скрипт удаления списка этих пакетов. Систему контролировать то надо. Другое дело, что если позже был установлен какой либо другой пакет, у которого в зависимости оказался такой же как и у предыдущего, тогда эту зависимость нельзя удалять. Но на это даже Debian не способен. Хотя меня убеждали в обратном. Он только удаляет какие то воспомогательные пакеты, которые у него в списке. Добавьте свой пакет, пропишите свои зависимости и Debian наложит в штаны. Такая хрень начнётся… Я уже пробовал. И задачей было не внедрить свой пакет, как это принято по их правилам, а как он(Debian) среагирует. Вывод - лучше контролировать систему самому, как это предлагает CRUX. Зато всё под контролем… А на счёт алгоритма удаления зависимых пакетов - непаханная целина нереализованных идей. Я уже не говорю про грандов, Debian, Fedora и прочих монстров… Тоже задолбались реализовывать. Поэтому, мой ответ такой - либо смирись с фактом, либо сам начинай думать.

Все просто. При установке каждой программы сохранять список пакетов, подтянутых по зависимостям. А потом, при удалении программ, предлагать удалить все пакеты из их списков.
Такое поведение, в виде плагина, должно занимать не более 1000 строк кода.

Добавлю apt autoremove к вышеотписавшимся

Всегда считал это весьма странной командой: почему это не делать автоматически? АВТОУДАЛЕНИЕ, которое нужно запускать вручную – дебиан-вей на марше!

пока в glibc не засунули зависимостью python3

в смысле, зависимость glibc от питона3 ?!!! КАК ?!

glibc 2.31 depends on python3 at build-time

спросите их, я не знаю зачем.

вот такая порнография теперь в CRUX 3.6:

Move python3 and dependencies to core

python3, expat, libffi, libtirpc, mpdecimal, sqlite3

но тут сам CRUX ещё раз повторюсь не при делах. glibc теперь требует питон3, а это значит скоро будет в LFS и других дистрибутивах.

хау~~~

glibc теперь требует питон3

Для сборки.

а это значит скоро будет в LFS и других сорс-базед дистрибутивах

Починил.

debian testing

~# sudo apt-cache show libc-bin
Package: libc-bin
Source: glibc
Version: 2.31-3
Essential: yes
Installed-Size: 3548
Maintainer: GNU Libc Maintainers <debian-glibc@lists.debian.org>
Architecture: amd64
Depends: libc6 (>> 2.31), libc6 (<< 2.32)
Recommends: manpages
Description-en: GNU C Library: Binaries
This package contains utility programs related to the GNU C Library.
.
* catchsegv: catch segmentation faults in programs
* getconf: query system configuration variables
* getent: get entries from administrative databases
* iconv, iconvconfig: convert between character encodings
* ldd, ldconfig: print/configure shared library dependencies
* locale, localedef: show/generate locale definitions
* tzselect, zdump, zic: select/dump/compile time zones
Description-md5: 7625903821514b57277d1bae69ec3c1a
Multi-Arch: foreign
Homepage: https://www.gnu.org/software/libc/libc.html
Tag: role::shared-lib
Section: libs
Priority: required
Filename: pool/main/g/glibc/libc-bin_2.31-3_amd64.deb
Size: 799544
MD5sum: bacbe6f5658dd079b85712c215a68bb1
SHA256: 93bb94ea3dbe0b086c5f519e6a4d3612afb87f465a0ea9ee448ee32afcff7425

~# sudo apt-cache show libc-bin|grep python
~#

Что курили мантейнеры крукса...

Сорри, не заметил ваш комментарий

Дебиан всегда был достаточно консервативен. Когда-то этой фичи не было, списки зависимостей никто не вёл (ТС, видимо, из тех времён середины 90-х, потому что с тех пор все нормальные ПМ уже умеюст вести те списки зависимостей, за которые он топит). Вот и добавили отдельной командой, чтобы не менять поведение и не поломать никому каких-то практик. С тех пор дебиан повернулся в сторону нового — поменял дефолтный инит, разрешил обновления некоторых программ в течение жизни релиза и т.д. А про эту фигню, видимо, просто забыли, когда делали apt на замену apt-* ☺ Так что не хватает только твоего багрепорта, чтобы сделать эту фичу по дефолту в apt, а в apt-get, так уж и быть, оставить всё по старому во имя обратной совместимости.

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

а зачем? не проще ли просто удалять все неиспользуемые пакеты?

Стоп, ты можешь просто подтвердить, что «хвосты» остаются, и никаким «автоматом» не вычищаются, для особо настырных? Этого было бы уже вполне достаточно.

Было бы глупо сносить пакет сразу после того, как он перестал использоваться, так что, «хвосты» нигде автоматом и не вычищаются.

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

под виндой конечно же!
там уже появились и пакетные менеджеры и зависимости.

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

Было бы глупо сносить пакет сразу после того, как он перестал использоваться

Why?

так что, «хвосты» нигде автоматом и не вычищаются.

Зависит от того, какую команду запускать.

примерно всегда остается мусор:

а на андроиде как удалить мусор?
а на афоне?
а в npm???

ладно, он в линуксе хотя бы остаётся в виде чётко deb-пакетов.

про остальную срань я вообще молчу.

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

и чтобы ты потом опять ставил амарок или deadbeeaf и опять скачивал ужасных 300 мб вместо 10 мб?
система умнее тебя, запомни это.

И это прекрасно, меня полностью устраивает этот ответ.

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

Следующую версию обычно ставят обновлением пакета, а не удалением.

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

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

Следующую версию обычно ставят обновлением пакета, а не удалением.

если только разница не мажорная, например питон2 и питон3, куте4 и куте5

или вообще смена ПО с одинаковым функционалом, например, смена DE Мате на Синаммон

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

да

или ещё, как вариант, ПО с непересекющимися задачами, но использующими общие либы, пример: установил фаерфокс - подтянул гтк, удалил фаерфокс - удалил гтк, поставил гимп - теперь снова подтягивать гтк, удалил гимп, поставил опеноффис - снова тянуть гтк

причём, чем жирнее пакет, тем с большей вероятностью он понадобится разношёрстному ПО => тем чаще его придётся туда-сюда гонять

т.е. реальная экономия при автоудалении будет на мелких пакетах, которые все вместе займут, допустим, 50Мб от силы

• риск нарушения стабильности системы

Пример 1:

1. Я установил программу Х
2. Программа Х. заисит от питон3
3. Я написал скрипт на питон3 и засунул его в кронтаб
4. Теперь у меня есть задача, которая отлично выполняется по расписанию
5. Удалил программу Х.
6. Авторемов удалил питон3
7. Теперь моя задача сломана, но я даже не знаю об этом ??? фейл

Пример 2:

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

Допустим, многие действительно пользуются программами, которые притянуты по зависимостям, тогда, есть ли где-нибудь вообще функционал, который выводит список этих пакетов-«хвостов», с возможностью удалить их в 1 клик? Если поведение, с предложением удалять их по LPD, вынесенное в название темы, тебе не нравится.

apt autoremove

Ты хоть сам то понимаешь чем это чревато?

Ты установил пакет А: Он притянул пакеты Н и М,

Ты Установил пакет Б который зависит от пакета М, но поскольку он уже установлен, то в твой «список» он не попал.

Ты удалил пакет А вместе с пакетами Н и М. Пакет Б теперь не работает.

Практический все пакетные менеджеры в таких случаях помечает пакеты А и Б как установленные вручную. А все что они притянули - как зависимости/автоматический установленные.

Авто-удаление есть практически везде - по дефолту не задействовано по упомянутым уже тут причинам (А вдруг ты захочешь пакет вернуть). В apt есть еще suggested and recommended которые поумолчанию тоже ставятся и отмечаются как установленные вручную, по этому они не удаляются при autoremove.

Если не хочешь заносить в систему «мусор», то грамотно настроенный пакетный менеджер будет удалять все неиспользованные/осиротевшие пакеты.

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