Cupt 2.0.0

>dpkg -l *edit*

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

Turbid (17.04.2011 22:49:20)

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

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

Zubok (17.04.2011 22:51:08)

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

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

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

elipse (17.04.2011 22:57:26)

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

это ты к чему?

Turbid (18.04.2011 0:08:01)

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

elipse (18.04.2011 0:24:28)

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

я про это.

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

Turbid (18.04.2011 1:19:36)

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

ага, "сам дурак"

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

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

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

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

elipse (18.04.2011 1:38:15)

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

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

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

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

overmind88 (18.04.2011 10:38:47)

ну так, 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".

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

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

tailgunner (18.04.2011 16:36:05)

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

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

GotF (18.04.2011 16:53:43)

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

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

GotF (18.04.2011 16:59:46)

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

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

GotF (18.04.2011 17:00:58)

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

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

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

Zubok (18.04.2011 17:49:16)

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

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

GotF (18.04.2011 17:52:53)

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

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

tailgunner (18.04.2011 17:58:19)

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

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

JackYF (18.04.2011 18:43:11)

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

Mystra_x64 (18.04.2011 18:53:19)

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

Vudod (18.04.2011 22:01:32)

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

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

tailgunner (18.04.2011 22:04:23)

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

franchukroman (18.04.2011 23:08:58)

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

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

JackYF (19.04.2011 0:45:37)

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

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

argin (19.04.2011 11:12:31)

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

>это windows way

Почему?

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

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

JackYF (19.04.2011 12:00:35)

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

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

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

tailgunner (19.04.2011 12:06:26)

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

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

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

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

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

JackYF (19.04.2011 12:24:19)

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

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

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

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

JackYF (19.04.2011 12:42:12)

Зачем это? Если есть стандартные и удобные aptitude, apt-get и dpkg ? >>Если не удалось решить зависимости, подробно объясняется, почему (пример). Вот это радует.

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

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

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

tailgunner (19.04.2011 12:46:28)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

argin (19.04.2011 14:57:09)

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

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

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

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

JackYF (19.04.2011 14:59:49)

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

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

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

JackYF (19.04.2011 15:07:08)

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

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