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 этот код - кажется он там был. > > >> - добавить функцию dist-upgrade > > Если это для перехода с 3.1 на 3.0 то не проще ли сделать отдельный > > бакенд для этого? > Я честно говоря не уверен, что это вообще необходимо, и уж > во всяком разе не в первую очередь. Для начала хорошо бы > убедиться в принципиальной возможности dist-upgrade > с дистрибутива на дистрибутив (мы ведь о дистрибутивах ведём речь ?) Это правильно. Сначала основное надо сделать. P.S. Сегодня завтра посмотрю на apt-shell и скажу что там можно сделать на мой взгляд. _______________________________________________ Devel-conf mailing list [email protected] https://lists.altlinux.org/mailman/listinfo/devel-conf
