Sergey Bolshakov пишет: >>>>>> "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. Я настроен пессимистически в отношении > такого подхода, вероятно, из-за слабого владения с++. > именно так. > Альтернативный подход мог бы выглядеть как схемные биндинги в > libapt/librpm и логика на схеме, поскольку я не вижу > иного способа 'убрать тормоза' -- существующая прослойка > в виде apt-pipe/awk добавляет от силы 10% времени выполнения > большинства операций. > схемные биндинги заставят нас реализовать массу функций apt-shell'а на схеме. Я не владею схемой в должной для оценки трудозатрат мере. > >> - добавить функцию dist-upgrade > > Если это для перехода с 3.1 на 3.0 то не проще ли сделать отдельный > > бакенд для этого? > Я честно говоря не уверен, что это вообще необходимо, и уж > во всяком разе не в первую очередь. Для начала хорошо бы > убедиться в принципиальной возможности dist-upgrade > с дистрибутива на дистрибутив (мы ведь о дистрибутивах ведём речь ?) > нет, это нужно в первую очередь для обновлений. > >> - наверное несколько зафиксить профили установки. здесь надо подумать. > >> Сейчас мне не нравится то, что необходимо делать профили для локали > >> (из-за переводов). > > Я надеюсь lioka тут расскажет как у него были устроены эти профили и как > > он видит их улучшение. > Профили устроены как абстрактное двухуровневое дерево, > и я не вижу причин, по которым следовало бы их улучшать > в рамках alterator-packages. > Улучшения, вероятно, необходимы в инструментах генерации > таких профилей, вроде separator. > Можно пойти и таким путём.
Rgds, Rider _______________________________________________ Devel-conf mailing list [email protected] https://lists.altlinux.org/mailman/listinfo/devel-conf
