Да, ТСу нужно, чтобы было так: устанавливаешь пакет - устанавливается пакет и 5 пакетов по зависимостям, удаляешь пакет - удаляется пакет и 5 пакетов по зависимостям.

А по описанным причинам выходит ад и содомия: часть зависимостей после удаления пакета не удаляется, а aptitude рассуждает примерно так: «Ололо! Да это же оконный менеджер! Ну зачем его удалять? Пригодится! Ну и что, что тут уже 100500 оконных менеджеров установлено!» Я считаю такую политику пакетного менеджера крайне ублюдочной.

aptitude - уг :)
apt-utils педалит :)

Ви таки считаете, также как и я :)

Обоснуй.

autoremove

Часть поставленного могла быть метапакетами.

а причём тут два эмулятора терминала? O_____O

Какие ты знаешь типы зависимостей в Debian? Это тебе не RPM-based с их жесткими зависимостями by design. Цитата: «Понятие зависимостей в Debian и его производных отличается от принятого в большинстве других дистрибутивов (и вообще ОС Unix-семейства). Обычно различаются только
обязательные (или “жесткие”) зависимости, без удовлетворения которых установка и работа программы невозможна (например, зависимость от системных библиотек), и зависимости необязательные (”мягкие”), без разрешения которых программа сохраняет работоспособность, но удовлетворение их добавляет ей функциональности (например, зависимость links или mc от сервиса консольной мыши gpm).
В Debian зависимости имеют несколько градаций: обязательные (depends), настоятельно рекомендуемые (recommends), рекомендуемые умеренно настойчиво (suggests), конфликтующие (conflicts). Первая градация - это обычные “жесткие” зависимости. С последними тоже понятно - это, так сказать, анти-зависимости. Ну а настоятельно рекомендуемые и рекомендуемые просто - это две разновидности “мягких” зависимостей. То есть первая категория как бы более нужная, нежели вторая. Впрочем, таково субъективное мнение майнтайнера данного пакета - вполне возможно, что у пользователя будут иные потребности.»
Пруф: http://alv.me/?p=240

Лол, ну это они как бичи сделали. Два эмулятора терминала тоже будут конфликтовать?

Два эмулятора терминала, предоставляющие разные версии одного и того же бинарника, несовместимые между собой - да.

Читаю тред и всё меньше понимаю, за что apt называют самым вменяемым пакетным менеджером. И всё больше люблю свой pacman. :-)

> autoremove

Плохие новости, дружок. Aptitude делает это автоматически :(

Плохие новости, дружок. Aptitude делает это автоматически :(

ЕМНИП не всегда. Лучше руками, команду я написал чуть выше.

Копипастить мануалы - скилл. Особенно когда проблема вообщем-то уже решена.

Всегда. Написанное тобой делает немножко другое. Оно вычищает конфиги всех удалённых пакетов. Кстати, apt так не умеет. Если наудаляешь без чистки конфигов, потом хрен найдёшь :3

А теперь обобщим - могут ли два пакета, предоставляющих один и тот же виртуальный пакет, быть установленными вместе?

Извини, все посты не читал. А основы все равно надо знать.

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

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

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

> В Арче виртуальные пакеты организованы нормально, а не через жопу,

Спасибо, я уже понял что ты фанатик.

поэтому обычно такой проблемы не возникает

Если это в арче невозможно by design - обоснуй. А твои догадки тут никому не нужны.

не знаю.

- скромно прибавил ты по теме, побросавшись говном. Вспомни-ка пару виртуальных пакетов, покажу тебе фокус с пакманом.

Ну день-то будний, чего ж ты хочешь )

Все нормально )

Кстати у меня ни разу не получилось в Арче удалить пакет сразу вместе с зависимостями.

> а причём тут два эмулятора терминала? O_____O

Они оба предоставляют виртуальный пакет. x-terminal-emulator или что-то в этом духе. Если два пакета, предоставляющих один виртуальный пакет, можно установить вместе, то в арче скорее всего можно будет воспроизвести это «странное» поведение.

Всегда. Написанное тобой делает немножко другое. Оно вычищает конфиги всех удалённых пакетов.

Хм, что-то меня опять переглючило...

Сейчас агрессивно настроенные друзья-арчеводы скажут что ты неосилятор.

Не сомневаюсь. Но почему в deb-системах мне достаточно набрать aptitude remove packageName, а в Арче для этого нужен какой-то хитрый скрипт? Это что - и есть KISS?

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

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

Напрямую. Если б ты знал про тамошнюю систему зависимостей и сделал aptitude show thunar, скажем, то такого вопроса ты бы вообще не задал.

Ох, эти наивные дети.

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

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

Ты чертовски популярен :D

читаю тему и всё больше ох/\/фигеваю. ЛОР всё же адски познавателен!

Дело в том, что бывают пакеты установленные по зависимости, и пакеты, установленные по рекомендации...

этот ответ точно мне?

я ж серьёзно- прочтя тред узнал много интересного.

Тред не читай @ Сразу отвечай

Этот вариант был бы правдоподобен, если бы в настройках aptitude не была запрещена установка рекомендованных пакетов. О чем в треде говорилось уже раза 4 точно.

aptitude why thunar пробовал набирать?

Кроме того, объяснение уже найдено, но ЛОР бескомпромиссен и беспощаден %)

чо? установка рекомендованных пакетов не равна неудалению рекомендованных пакетов

Еще до создания этой темы, мой друг. А вывод красуется на первой странице, да.

тут вроде только об этом и говорили )

Мой друг, открой эмулятор терминала, набери aptitude, нажми Enter. Затем С-T для меню, пять раз нажми строчку вправо, затем - стрелочку вниз. Ты увидишь пункт «Предпочтения». А затем вдумчиво прочти пояснение к настройке «Автоматически удалять неиспользуемые пакеты».

Если это в арче невозможно by design - обоснуй.

Это возможно, но так не происходит. Потому что в пакетах просто грамотно прописаны зависимости.

Вспомни-ка пару виртуальных пакетов, покажу тебе фокус с пакманом.

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

> Это возможно, но так не происходит. Потому что в пакетах просто грамотно прописаны зависимости.

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

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

Тут просто какая-то другая концепция пакетных менеджеров нужна -_-

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

Ну или пересмотреть принцип виртуальных пакетов. Либо для автоустановленных пакетов запоминать, зачем их установили. Варианты есть.

Тут просто какая-то другая концепция пакетных менеджеров нужна -_-

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