Stanislav Ievlev пишет: > On Fri, Mar 03, 2006 at 07:44:56PM +0300, Sergey Bolshakov wrote: > >>>>>>> "Stanislav" == Stanislav Ievlev <inger-u2l5PoMzF/[EMAIL PROTECTED]> >>>>>>> writes: >>>>>>> >> > On Fri, Mar 03, 2006 at 05:41:42PM +0300, Anton Farygin wrote: >> >> Привет. >> >> >> >> То, что хотелось бы изменить в существующей установке пакетов (третья >> >> стадия): >> >> >> >> - убрать тормоза. Это можно (на мой взгляд) сделать как минимум за счёт >> >> переписывания backend'а.. а дальше - Стас, как оптимизировать >> >> - добавить больше интерактивности - при выборе пакетов выводить диалоги >> >> со списками чего будет установлено, при ошибках установки - выводить что >> >> именно за ошибки. >> > Кстати интересно, как это сделать. apt-shell даёт такую информацию? >> apt-shell даёт, кое-как. >> >> >> это на мой взгляд можно реализовать только изменением бакэнда (взять >> >> apt-shell, на его базе сделать apt-backend) >> > Давайте попробуем вспомнить какие вызовы нам требовались от apt-shell. >> > Нынче мы можем делать ненативные бакенды с состоянием, поэтому как-минимум >> > apt-pipe можно уже не использовать ... не знаю хорошо это или плохо, уж >> > больно медленно этот apt-shell поднимается, кстати почему? >> >> Если делать ненативный бакенд из apt-shell, то не стоит и начинать -- >> текущее решение худо-бедно работает. >> Худо в том смысле, что распознавать/парсить _все_ возможные ошибочные >> состояния он не умеет, что и вылезало в случае кривого носителя. >> Повторять этот же путь на схеме вместо awk -- себе дороже. >> Антон, как я понимаю, предлагает избавиться от прослойки >> на awk/scheme и выдавать ответы в формате, максимально близком к >> принятому в alterator. Я настроен пессимистически в отношении >> такого подхода, вероятно, из-за слабого владения с++. >> > Боюсь что это худо в глазах пользователей выглядет больше чем бедно. awk > всё-таки не искуственный интелект, поэтому гарантированно надо будет > подумать насчёт упрощения изначального формата данных. А то "внутренняя > ошибка commit" уже стала классикой Compact 3.0 . > Верно. >> Альтернативный подход мог бы выглядеть как схемные биндинги в >> libapt/librpm и логика на схеме, поскольку я не вижу >> иного способа 'убрать тормоза' -- существующая прослойка >> в виде apt-pipe/awk добавляет от силы 10% времени выполнения >> большинства операций. >> > Чистые биндинги вряд ли имеют смысл, а вот C-шный код, который возьмёт на > себя основную работу + биндинги - это будет разумной золотой серединой. > не уверен. > Ещё важный момент . Какая дополнительная логика находится в apt-shell, по > сравнению с libapt? Может быть мы сможем просто часть прооптимизировать - > apt славится тем что делает массу ненужных действий, есть подозрение что и > apt-shell не > исключение. Помнится voins после упрощения куска кода для получения списка > пакетов получил ускорение раз эдак в 10 - надо будет видимо вытащить из > TLA этот код - кажется он там был. > Сам apt-shell работает достаточно быстро. Тормоза идут: - при первом запуске, и от этого избавиться не получится - надо просто выводить сообщение "чтение базы данных пакетов" - при различных листингах, когда на каждое открытие идёт пачка запросов к backend'у - при включениях/выключениях групп из профилей - там вообще ужасная логика по коммитам в бэкенд.
Всё остальное работает более-менее быстро. >> >> - добавить функцию dist-upgrade >> > Если это для перехода с 3.1 на 3.0 то не проще ли сделать отдельный >> > бакенд для этого? >> Я честно говоря не уверен, что это вообще необходимо, и уж >> во всяком разе не в первую очередь. Для начала хорошо бы >> убедиться в принципиальной возможности dist-upgrade >> с дистрибутива на дистрибутив (мы ведь о дистрибутивах ведём речь ?) >> > Это правильно. Сначала основное надо сделать. > dist-upgrade необходим для установки updates, в первую очередь. > > P.S. Сегодня завтра посмотрю на apt-shell и скажу что там можно сделать на > мой взгляд. > Посмотри ;) не забывай, что apt-shell по своей сути == apt-get + apt-cache + ещё чтото, объдиненное в одно целое. Rgds, Rider _______________________________________________ Devel-conf mailing list [email protected] https://lists.altlinux.org/mailman/listinfo/devel-conf
