Cupt 2.0.0

>dpkg -l *edit*

вопрос был про apt vs aptitude, не? и если я не ошибаюсь в dpkg шаблоны только по имени пакета, а aptitude еще по состоянию, описанию и т.д.

>да и дело не в этом, суть то в том чтоб функцию совсем отсечения всего лишнего без чего пакет встанет, можно отсечь и video-all и xorg встанет но если не сделать этого щас вручную то и aptitude этого не сделает и поставит его

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

бгг, а что, установка aptitude непременно должна приводить к травме головы (ну или системы) ?

а aptitude еще по состоянию

да ерунда какая:
dpkg -l *edit* > file
там тебе и состояние и описание будет.
ну если выхлоп в один экран не влез от «наложенного хфильтра» )

>бгг, а что, установка aptitude непременно должна приводить к травме головы (ну или системы) ?

это ты к чему?

Ну один купоросит мозги, что aptidude избавляет Debian от слаки, а другой норовит сделать вид, что система ущербна без aptidude.
Отсюда и напрашивается вывод, что использование aptidude приводит
к деградации квалификации (ну как правило) , снижению способности выживать, ну и какому-то назойливому мифотворчеству.

aptitude - инструмент, который заменяет в большинстве случаев dpkg, apt и dselect. 99% операций с пакетами я делаю в нем (раз в год использую dpkg -i и apt-cache-policy).

я про это.

а то что ты там дальше додумал - твои проблемы.

а то что ты там дальше додумал - твои проблемы.

ага, «сам дурак»

aptitude - инструмент,

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

который заменяет в большинстве случаев dpkg, apt и dselect.

А прикол в том, что именно таки не заменяет.

>И надеяться, что всё это уживётся вместе и не поломают систему. Увы в 2 раза больше системных программ - в 2 раза больше багов.

хм, дак это ж как там - unix way - одна утилита решает одну задачу, linux way - много утилит решает одну и ту же задачу. Все просто.

> Меньше шансов превратить систему в слаку.

Лол, дебианщики умудряются аптом превратить систему в слаку?

ну так, Linux Is Not Unix же.

>ну так, Linux Is Not Unix же.

правильно, поэтому лялех и скатился до уровня второй венды. Сейчас еще пару workaround-ов в либах и ядре под баги всяких приложений (Линус же за такую политику) и все в порядке будут.

А то что есть много утилит реализующих одно и тоже одинаково по кривому - это уже диагноз.

Опробовал. Субъективно в много раз быстрее perl'ового варианта.

Разделяю политику автора относительно ошибок и предсказуемого поведения. Если произошла ошибка, то нужно останавливаться. Как вариант, опция, позволяющая игнорировать ошибки, но это для экспериментаторов.

aptitude меня периодически весьма неприятно удивляет предложенными решениями. В данный момент, например, на Debian unstable (обновлялся несколько месяцев назад) при попытке поставить audacious из-за конфликта зависимостей aptitude предлагает снести полгнома, в частности nautilus, gnome-panel и т.п. (итого 67 пакетов удалить, 33 поломать)

cupt корректно предлагает поставить (и обновить по зависимостям) те же 67 пакетов. Несомненный win же!

Кроме того, чтение кэша пакетов и предложение первого варианта (напоминаю, у aptitude он неправильный) для cupt происходит в 4 раза быстрее: user 0m0.333s (cupt) против user 0m1.246s (aptitude).

(Честно отказался от установки плеера на случай, если кто-то затребует в студию скриншоты)

Поправка: не тех же пакетов. Обновляются некоторые другие, только что внимательно проверил.

Попробуй не делать autoremove -> бардак ещё тот. А потом «оно удалило мне всю систему!!11».

Спокойно, слюни летят.

А эта штука умеет работать на системе со слегка поломанными зависимостями?

>> aptitude - инструмент, который заменяет в большинстве случаев dpkg

dpkg ты им не заменишь, он его использует.

>> Лично я считаю, что зависимость хитрая слишком.

А что хитрого в зависимости «или»? Неудобно просто бывает с нею, т.к. первый вариант из списка не всегда устраивает. Например, в Squeeze вроде можно поставить dokuwiki без apache и его кусков, но это требует учёта таких «альтернативных» зависимостей у двух пакетов как минимум: самой dokuwiki и php-чего-то-там, если память не изменяет.

>> Попробуй не делать autoremove -> бардак ещё тот.

APT::Get::AutomaticRemove «Yes»; — и ничего (вручную) делать уже не надо.

Сложный вопрос. У меня бывало (на капте 1.2) не расставляло nonauto флаги, потом тот же apt-get и aptitude ругались. Сейчас подобного нет.

>А что хитрого в зависимости «или»? Неудобно просто бывает с нею, т.к. первый вариант из списка не всегда устраивает.

Может быть, я не сомвсем ясно выразился. Я имел в виду циклическую зависимость xserver-xorg-core -> xserver-xorg -> xserver-xorg-core. Я не совсем понимаю, какой в ней был смысл. Только с твоей подачи увидел, сам не натыкался никогда, так как ставил xorg на неск. машин, зажмурившись. Ставит кучу драйверов, и пускай. И даже recommends все ставил. Я только предполагаю, что она раньше эта зависимость существовала из каких-то причин, возникающих при обновлении дистрибутива. После нескольких лет эту зависимость обозвали hell'oм, закрыли чей-то старый багрепорт.

>> Я имел в виду циклическую зависимость xserver-xorg-core -> xserver-xorg -> xserver-xorg-core.

А, тогда, пожалуй, согласен.

> Сложный вопрос. У меня бывало (на капте 1.2) не расставляло nonauto флаги

Не, я не про noauto. Предположим, в системе стоит пакет, зависимости которог не удовлетворены (apt отказывается работать и говорит «сделайте apt-get install -f»). Как ведет себя cupt?

>Не, я не про noauto. Предположим, в системе стоит пакет, зависимости которог не удовлетворены (apt отказывается работать и говорит «сделайте apt-get install -f»). Как ведет себя cupt?

Предложит исправить зависимости, если возможно, а если невозможно, то изменять систему не будет.

Ну и зачем он такой нужен, где это можно отключить? :]

Надо будет его попробовать, а то аптитуда не всегда меня устраивает.

> Предложит исправить зависимости, если возможно

Пример: нужно поставить/обновить/удалить пакет, и он не касается не касается сломанных зависимостей. cupt выполнит операцию или откажется?

cupt давно использую (со времен Lenny) Он намного лучше решает зависимости в ситуации, когда подключено несколько веток.

>Пример: нужно поставить/обновить/удалить пакет, и он не касается не касается сломанных зависимостей. cupt выполнит операцию или откажется?

Откажется. Иными словами, cupt откажется делать любое изменение в системе, результатом которого оказывается система со сломанными зависимостями.

>Откажется. Иными словами, cupt откажется делать любое изменение в системе, результатом которого оказывается система со сломанными зависимостями.

это windows way. Программа не должна думать вместо пользователя. Она имеет право ему советовать, но решать вместо пользователя неправильно

>>Откажется. Иными словами, cupt откажется делать любое изменение в системе, результатом которого оказывается система со сломанными зависимостями.

это windows way

Почему?

Программа не должна думать вместо пользователя. Она имеет право ему советовать, но решать вместо пользователя неправильно

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

>>Пример: нужно поставить/обновить/удалить пакет, и он не касается не касается сломанных зависимостей. cupt выполнит операцию или откажется?

Откажется. Иными словами, cupt откажется делать любое изменение в системе, результатом которого оказывается система со сломанными зависимостями.

Кхм. Вообще-то зависимости были сломаны _до_ изменения, которое запрошено у cupt. И в результате работы cupt они не сломаются.

Интересная логика. Вообще, верно, в результате работы менеджера состояние системы не должно ухудшаться, поддерживаю.

Жень, вообще возможно как-то учитывать вместо конечного состояния системы изменение оного? Это будет действительно killer-feature. Пусть ругается, пишет тонны текста, если зависимости поломаны, но если установка пакета никак не связана с поломанными, то что мешает установить новый пакет?

>Кхм. Вообще-то зависимости были сломаны _до_ изменения

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

Да, теоретически можно сделать и по-другому — что ж, cupt не идеален. Но мне этот сценарий использования не интересен, по крайней мере, пока не решены более насущные проблемы.

>Жень, вообще возможно как-то учитывать вместо конечного состояния системы изменение оного? Это будет действительно killer-feature.

Неужели это действительно востребовано? Да, теоретически можно, хоть и непросто.

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

Если никак не связана, да, можно реализовать. Заведите кто-нибудь wishlist-баг.

Зачем это? Если есть стандартные и удобные aptitude, apt-get и dpkg ?

Если не удалось решить зависимости, подробно объясняется, почему (пример).

Вот это радует.

>> Это будет действительно killer-feature.

Неужели это действительно востребовано?

Это удобно временами (особенно когда делаешь свои пакеты :)). Но вряд ли это killer feature - IIRC, это умел Smart, который так и не взлетел.

> Неужели это действительно востребовано?

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

Эта фича востребована при поломке зависимостей:

а) Вручную при экспериментах с dpkg и gdebi. Это, конечно, следствие невежества или самоуверенности, однако не переставлять же кучу файлов по глупости, верно?

б) При использовании сторонних репозиториев (тот же skype, frickelplats gimp, winehq).

в) В случае сбоя пакетного менеджера.

Где можно вписать wishlist?

Есть две штуки: 1. то о чем говорил tailgunner: опция для работы с поломанным состояним репозитория 2. в режим 'a' при модификации списка пакетов добавить модификатор для пакета для purge (пока видел только + для add и - для remove).

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

>Почти единственное назначение менеджеров пакетов высокого уровня - думать вместо пользователя.

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

Экстремалы, работающие на системах со сломанными зависимостями, могут вызывать dpkg вручную.

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

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

Кроме того, направленность на восстановление целостности системы не означает самоотключение при её отсутствии. ПМ может мне посоветовать удалить какие то пакеты, или доставить какие то пакеты.

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

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

>Где можно вписать wishlist?

'reportbug cupt', и выбрать wishlist из списка, когда спросят.

Есть две штуки:

Да, это заслуживает двух отдельных wishlist'ов.

>И тогда таким пакетным менеджером я не смогу восстановить систему.

Нет, почему же. Cupt по-умолчанию просто либо доставит сломанные зависимости, либо предложить удалить всё сломанное. Если пакеты некритичные, их можно будет переставить потом. Не очень удобно, да.

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

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

Весьма полезная была бы возможность. С debian stable/testing мне такое ни разу не нужно было, но с тем же AltLinux(apt+rpm) помню несколько раз приходилось ставить отдельные пакеты с --no-depends и как следствие отказываться от apt, что весьма огорчало. Приходилось создавать fake пакеты для удовлетворения apt. Так что пусть cupt ругается на текущее состояние, но продолжает выполнять install, хотя бы даже с отдельным ключиком --force.