24 марта 2012 Michael Pozhidaev написал:
> > Плохо, что в ТТ не прописан механизм внешнего API. Меня лично интересует
> > API для установки/удаления/обновления пакетов с callback/слотами под
> > асинхронные события, возникающие при ошибках и при прогрессе.
> 
> Андрей, давай зайдём с другой стороны. Какого рода клиента для этого API
> ты обдумываешь? Вообще, API - здесь принципиально важная вещь,
> которую без внимания оставлять нельзя. В частности, у меня есть парочка
> инициатив, которые не решают насущные текущие проблемы, но далее хотел
> бы их рассмотреть. Они могут быть реализованы как отдельные
> приложения на основе API Deepsolver.
Во-первых, есть мой пакет packageinstall, который ставит пакеты в графическом 
интерфейсе. Там столько костылей и подпорок для текущего apt, что надо 
переделывать.
Во-вторых, zerg@ хорошо бы было заменить установку из его apt-indicator через 
Synaptic на нечто более лёгкое.
В-третьих, клиент по установки приложений (который aen@ спит и видит) 
стопорится как раз из-за компонента установки пакетов.
В-четвёртых, есть ужасный хак под названием alterator-packages

Кроме того, у пользователей есть проблемы забывания apt-get update, да и 
процедура это не из быстрых в apt-rpm. Напрашивается демон apt, сидящий в 
оперативке.

Мне бы хотелось следующее (на первом этапе):
1. Доступ к поиску/установке/удалению из C++ (желательно иметь биндинги и из 
Python). Для разработки удобнее чтобы для написания клиента нужно было 
подключить библиотеку и использовать её функции.
2. Природная асинхронность операций предполагают использование системы 
сигналов для информирования об ошибках и прогрессе. Это нужно чтобы в клиенте 
показывать прогресс и реагировать на возможные ошибки. На Qt это делается с 
помощью сигналов/слотов. Как здесь - тебе решать, я и на callback-функции 
согласен. Уже это будет большим шагом вперёд по сравнению с парсингом apt-
pipe.

-- 
Андрей Черепанов
ALT Linux
cas@altlinux.ru