ALLIGATOR (менеджер пакетов)

[alexis031182]

Не радует, что зависимость от rpm тогда появится. Пожалуй надо разработчикам ALTLinux письмо написать, может кто ответит на возникший вопрос.

[romuil]

Работа с внутренностями rpm возможна только средствами rpm.
В man rpm все есть по списку файлов в пакете, в том числе и по неустановленным пакетам, и при их локальном наличии, например в репозитории на жестком диске.
apt вообще не предназначен для таких действий, придется делать версию для deb и rpm.
Подключая соответственно dpkg и rpm.

[alexis031182]

Работа с внутренностями rpm возможна только средствами rpm.
В man rpm все есть по списку файлов в пакете, в том числе и по неустановленным пакетам, и при их локальном наличии, например в репозитории на жестком диске.
...

Так вот в том-то и дело, что пакеты-то находятся удалённо, т.е. в таком случае можно рассматривать как вариант получение списка файлов пакета через Интернет.

[romuil]

С этим можно разобраться например читая список файлов из spec.
Правда придется выгребать пути из макросов.

[alexis031182]

С этим можно разобраться например читая список файлов из spec.
Правда придется выгребать пути из макросов.

Да, но эти файлы также находятся удалённо. Не скачивать же их все...

[alexis031182]

Решил всё-таки инкрементировать текущую версию проекта до 0.0.1.7. Доступна здесь. Уже сделано много изменений в коде, хотя и не достигнута та функциональность, что планировалась изначально. Проблема, как я уже написал выше, заключается в получении списка файлов пакета. Мне дополнительно придётся затратить время на хотя бы поверхностное изучение rpm-библиотеки.

Далее идут зависимости... Тут проблем особых нет, но прежде чем что-либо городить, я хочу посоветоваться, каким наиболее оптимальным образом данную информацию можно пользователю показать. Дело в том, что у каждого пакета может быть несколько версий файлов. В свою очередь, каждая версия файла может иметь свои зависимости, причём также делящиеся по виду: "зависит(-ят) от меня" и "я завишу от". Понятное дело, что в каждый момент времени пакет какого-либо приложения может быть установлен только одной версии, а может быть вообще не установлено ничего. Так вот, исходя из текущего построения виджетов в проекте, я хотел бы услышать ваши мнения по поводу, каким образом мне это дерево зависимостей построить в окне программы.

Ещё одна проблема: программа "жрёт" много памяти (у меня аж 70 мегабайт). Подозреваю, что надо немного переделать алгоритм работы, дабы не создавать того, что в данный момент выполнения вовсе не используется. Пожалуй лучше пусть она пару секунд дольше будет думать над какой-либо операцией, нежели потом ей понадобятся все ресурсы компьютера.

Теперь о хорошем: хорошего мало. Да и ладно... Главное, что дело движется.

ЗЫ. Огромная просьба: я, к сожалению, наверняка не смог самолично отследить все проблемы в работе приложения. Если у кого есть время помочь проекту в поиске багов, посодействуйте. Спасибо.

Ой! Чуть не забыл. Вот скриншоты на всякий случай:

[alexis031182]

На ftp выложил запакованный бинарник, если кто не хочет компиляцией заниматься.

[alexis031182]

Планы на 0.0.1.8:

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

[Skull]

Упс! Инициализация пакетов не выполнена.
Нужно всё же писать демон, который кэширует список пакетов и осуществляет над ними операции. А уж для него писать фронт-энд.
- в графической программе нужен быстрый фильтр по пакетам
- с точки зрения юзабилити значки неустановленных пакетов сделать не тёмно-серые, а светлые или вообще незакрашенную окружность
- в списке обязательно указывать версию пакета
- сделать панель инструментов

[alexis031182]

Упс! Инициализация пакетов не выполнена.

Может из-за того что не root?

Нужно всё же писать демон, который кэширует список пакетов и осуществляет над ними операции. А уж для него писать фронт-энд.

Простите, мы тут уже обсуждали вроде эту тему по поводу демона. Никто не высказался "за", я разработку его прикрыл. Можете ли вы аргументировать, почему именно с демоном приложение должно быть. А то как в басне получается.

- в графической программе нужен быстрый фильтр по пакетам

Да, обязательно будет сделано.

- с точки зрения юзабилити значки неустановленных пакетов сделать не тёмно-серые, а светлые или вообще незакрашенную окружность

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

- в списке обязательно указывать версию пакета

Версию? Точно ли надо? И какую? Если пакет установлен, то понятно - установленную, а если не установлен, то самую новую, так? Вообще, я планировал версии указывать в нижнем виджете. Там уже с ними "разборки" устраивать можно.

- сделать панель инструментов

Это к обязательному исполнению.

[alexis031182]

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

Есть мнения?

[Skull]

Упс! Инициализация пакетов не выполнена.

Может из-за того что не root?

Так и есть. После этого окно недоступно (нужно запускать в отдельной нити (thread), чтобы интерфейс не замораживался.

- Кроме того, у значка в системном лотке нет контекстного меню, позволяющего закрыть приложение.
- Нет прокрутки в описании и невозможно выделить описание. Нужно делать его многострочным полем ввода, защищённым от записи
- Не показываются зависимости
- В виде по группам не обновляется описание при переходе по пакетам.
- Некоторые пакеты дублируются. Например, Приложения-ananas-extensions

Простите, мы тут уже обсуждали вроде эту тему по поводу демона. Никто не высказался "за", я разработку его прикрыл. Можете ли вы аргументировать, почему именно с демоном приложение должно быть. А то как в басне получается.

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

Версию? Точно ли надо? И какую? Если пакет установлен, то понятно - установленную, а если не установлен, то самую новую, так? Вообще, я планировал версии указывать в нижнем виджете. Там уже с ними "разборки" устраивать можно.

Версия имеет ключевое значение и можно указывать в стандартном виде. В synaptic это делается в двух столбцах: установленная и последняя. Можно указывать установленную, а если нет — последнюю.

[alexis031182]

Так и есть. После этого окно недоступно (нужно запускать в отдельной нити (thread), чтобы интерфейс не замораживался.

С этим я позже разбираться буду.

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

Честно говоря, добавил данную функцию, походя просматривая код другого своего приложения. Добавил и забыл на время. Безусловно, всё это будет доработано. Сейчас это не главное.

- Нет прокрутки в описании и невозможно выделить описание. Нужно делать его многострочным полем ввода, защищённым от записи

Уже сделал.

- Не показываются зависимости

Так я писал выше, что хотел бы услышать мнения других о том, как эти зависимости представлять (показывать ). Сейчас этим занимаюсь.

- В виде по группам не обновляется описание при переходе по пакетам.

Временно вид "По группам" замораживаю. А то сразу на всё меня не хватит.

- Некоторые пакеты дублируются. Например, Приложения-ananas-extensions

Да, моя ошибка. Исправлю.

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

Верно, меня тоже это несколько смущало, поэтому уже переделал код. Программа теперь работает немного по другому принципу. Думаю, сейчас по скорости вполне терпимо, сравнимо с Synaptic (уж его-то скорость загрузки я надеюсь никого не раздражает?).

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

Кстати, хорошим вариантом было бы использование демона вкупе с какой-нибудь базой данных. К примеру, демон мог бы периодически просыпаться и кэшировать информацию о пакетах, "загоняя" её в БД. Потом полностью освобождал бы занимаемые ресурсы и снова засыпал. Клиентскому фронтэнду оставалось бы только к БД подключиться и получить инфу практически мгновенно. Хотя тут конечно и за синхронизацией работы следить бы пришлось. Что думаете?

Версия имеет ключевое значение и можно указывать в стандартном виде. В synaptic это делается в двух столбцах: установленная и последняя. Можно указывать установленную, а если нет — последнюю.

Уже сделал в виде "Стандартный".

[Skull]

Что касаемо демона... Вы не ответили на вопрос. Зачем, по вашему мнению, нужен демон? Только лишь для увеличения скорости загрузки.

Не только.
1. Для быстрой загрузки
2. Для моментального обновления после удаления/установки
3. Для быстрого поиска
Есть много мест, где задержка раздражает.

Перевешивает ли этот плюс, расходы на память?

Да.

Кстати, хорошим вариантом было бы использование демона вкупе с какой-нибудь базой данных. К примеру, демон мог бы периодически просыпаться и кэшировать информацию о пакетах, "загоняя" её в БД.

База — слишком большой оверхед. Может быть, какой-либо вариант sqlite или berkley db, а можно просто кэш. Посмотрите, как реализован gconf/sycoca.

Хотя тут конечно и за синхронизацией работы следить бы пришлось. Что думаете?

Это в любом случае придётся. Если будет работать через демон, то синхронизировать легко, а вот для изменений, сделанных сторонними программами придётся ловить сообщения inotify изменения файлов и перечитывать список.

[alexis031182]

Не только.
1. Для быстрой загрузки
2. Для моментального обновления после удаления/установки
3. Для быстрого поиска
Есть много мест, где задержка раздражает.

Ну хорошо. Видимо вы и я пользуемся менеджером пакетов довольно часто. В таком случае вопрос: нужно ли такое приложение тем пользователям, что занимаются обновлением собственных систем от силы раз в месяц, а то и реже? Нужен ли им этот, в данном случае получается, якорь? Думаю нет. Здесь мы находимся, собственно, перед выбором. Два лагеря с противоположными мнениями. Ну и какой может быть выход из сложившегося положения по вашему мнению?

База — слишком большой оверхед. Может быть, какой-либо вариант sqlite или berkley db, а можно просто кэш. Посмотрите, как реализован gconf/sycoca.

Посмотрю обязательно.

Это в любом случае придётся. Если будет работать через демон, то синхронизировать легко, а вот для изменений, сделанных сторонними программами придётся ловить сообщения inotify изменения файлов и перечитывать список.

Я не совсем понял, о каких сторонних программах идёт речь? О Synaptic, Alterator? Ну наверное здесь тоже можно что-то придумать, да и как правило пользователи не пользуются несколькими менеджерами одновременно. Или вы говорите о непериодическом обновлении демоном кэша, а по событию, например после установки какого-либо пакета? Данный вариант вообще красота, но вот методы отлавливания подобных сигналов мне неизвестны. Что имеется ввиду под словом "inotify"?

[Alexei_VM]

1. Для быстрой загрузки
2. Для моментального обновления после удаления/установки
3. Для быстрого поиска
Есть много мест, где задержка раздражает.

Демон не нужен!

Загрузку чего он ускорит? Менаджера пакетов? И часто он запускается? Раз в неделю? Раз в месяц? А то может так дойдем еще и до того, что нужно все архивы-бэкапы распаковать в память, и там хранить, а то вдруг надо будет чего за прошлый год в архиве поглядеть, а он распаковывается долго.

Для моментального обновления чего?
Для быстрого поиска? apt-cache ищет долго только в первый раз, потом все нужные сведения оседают в кэше. Один раз можно и подождать, тем более, что apt применяется НЕЧАСТО, это не бравзер, не почтовик, и не медиаплеер. Вобщем, это не повседневный инструмент. Ускорять его работу смысла не имеет.

[alexis031182]

Мне, например, этим доводам возразить нечего. С другой стороны, я сам пользуюсь менеджером пакетов довольно часто. Но при этом, опять же, нельзя не согласиться, что длительное ожидание окончания загрузки происходит лишь при первом запуске. Далее всё работает достаточно быстро. Проходит несколько минут бездействия, и снова начинается долгий процесс кэширования.

Писать сразу две программы я не могу. Они принципиально отличаются друг от друга. Предлагаю поступить следующим образом: продолжить написание кода в ключе без демонизации, но при этом с критичным анализом ко времени исполнения каждой функции. Правда одна проблема сразу же проявится - моментально сжирается внушительный объём памяти, больше 100 мегабайт, т.к. настоящие репозитарии ALTLinux весьма и весьма внушительны по количеству пакетов.

Так что важнее?

[ToraBora]

Вопрос демон/не демон считаю не принципиальным, а вот функциональность и скорость работы Alligatora - очень даже важными характеристиками. Если для комфортной работы с Программой необходимо сделать её "демонической", то надо делать.
"Видимо вы и я пользуемся менеджером пакетов довольно часто... нужно ли такое приложение тем пользователям, что занимаются обновлением собственных систем от силы раз в месяц, а то и реже? Нужен ли им этот, в данном случае получается, якорь? Думаю нет."
Я думаю таким пользователям ничего кроме Синаптика и не нужно

[Skull]

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

Я лишь предлагал инженерное решение. Если ты считаешь, что это реализовать сложно, будем сидеть с задержками и кушать то, что дают. В таком случае возникает закономерный вопрос: зачем изобретать велосипед, чем Synaptic не устраивает?

Я не совсем понял, о каких сторонних программах идёт речь? О Synaptic, Alterator?

Угу. Но больше: apt-get и rpm.

Или вы говорите о непериодическом обновлении демоном кэша, а по событию, например после установки какого-либо пакета? Данный вариант вообще красота, но вот методы отлавливания подобных сигналов мне неизвестны. Что имеется ввиду под словом "inotify"?

Читай документацию. Это уведомление об изменении файла (в данном случае базы пакетов) средствами ядра. Так устроено индексирование в Beagle.

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

Задержка всё равно существенна.

[alexis031182]

Я лишь предлагал инженерное решение. Если ты считаешь, что это реализовать сложно, будем сидеть с задержками и кушать то, что дают. В таком случае возникает закономерный вопрос: зачем изобретать велосипед, чем Synaptic не устраивает?

Можно реализовать всё при должном терпении и желании. По поводу "будем сидеть с задержками и кушать то, что дают", не стал бы так горячиться. На самом деле, механизм Synaptica можно обойти в скорости и без использования демона. Говорю так, потому что сие у меня получилось, но, как я уже писал, многовато памяти расходуется.

Теперь о "велосипеде" и "чем Synaptic не устраивает". Об этом уже много раз говорилось даже на этом форуме. Не хочу повторяться.

Вообще мне стало казаться, что в предложениях о демоне имеется ввиду изобретение второго apt-pkg, ну или, скажем так, его апгрейд. Не компетенция ли последнего периодическое кэширование информации о пакетах? Не должно ли это быть реализовано там, а не в графическом фронтэнде, коим я и занимаюсь? По моему, задачи несколько не соответствуют. Разве не так? Там много чего можно было бы переделать и изменить, добившись в конце концов существенного увеличения скорости работы, но такой задачи я не ставил. Если этим заниматься, нужен другой проект. Да и без разработчиков ALTLinux в нём не обойтись. Ну скажи, что я не прав.

ЗЫ. Почему у вас до сих пор никто этим не занялся, раз не устраивает имеющаяся скорость работы и приходится "сидеть с задержками и кушать то, что дают"? Зато есть время поговорить о самокатах.

Читай документацию. Это уведомление об изменении файла (в данном случае базы пакетов) средствами ядра. Так устроено индексирование в Beagle.

Я с подобными вещами ещё не сталкивался, поэтому и спросил, дабы иметь точное представление о какой стороне вопроса идёт речь. Документацию читаю всегда.

Задержка всё равно существенна.

Ну если исходить из того, что "баба яга против", и не утруждать себя приведением аргументов в пользу собственного мнения, то как можно о чём-то договориться? Задача ведь не стоит в изобретении "супернавороченного" приложения для управления пакетами, моментально срабатывающего и выдающего результат от одного только взгляда или чиха. Мне, например, важнее было бы, если бы мой проект подходил большинству пользователей, но так, чтобы при этом и не мешал. Нужна скорость? Давайте будем оптимизировать алгоритм анализа метаданных, получаемых от apt-pkg. Нужна дополнительная функциональность? Давайте работать и в этом направлении. Нужна модернизация самой системы управления пакетами? Согласен, и здесь можно покумекать, но только в другом проекте. Есть предложения? Или ты по прежнему считаешь, что глобальная (с демоном) оптимизация в скорости должна производиться во фронтэнде?

[Skull]

Не должно ли это быть реализовано там, а не в графическом фронтэнде, коим я и занимаюсь?

Должно. Но не сделано.

ЗЫ. Почему у вас до сих пор никто этим не занялся, раз не устраивает имеющаяся скорость работы и приходится "сидеть с задержками и кушать то, что дают"? Зато есть время поговорить о самокатах.

Потому как есть множество более актуальных мест приложения сил. Если тебе нравится вести этот проект — замечательно. Чем сможем — поможем.

Ну если исходить из того, что "баба яга против", и не утруждать себя приведением аргументов в пользу собственного мнения, то как можно о чём-то договориться?

Если хочешь, я могу показать время задержки и апеллировать к требованиям эргономики пользовательского интерфейса. Думаешь, надо? Уж аргументы у меня всегда есть, толко я собеседником жалею, так как моя критика, как правила, очень жёсткая.

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

Если речь про ALT Linux, то правильнее было бы сделать модуль к Alterator. Это к вопросу о консистености пользовательского интерфейса.

Или ты по прежнему считаешь, что глобальная (с демоном) оптимизация в скорости должна производиться во фронтэнде?

Я не считаю, а предлагаю, как одну из мер. Перечитай мой пост внимательнее.

[alexis031182]

Если хочешь, я могу показать время задержки и апеллировать к требованиям эргономики пользовательского интерфейса. Думаешь, надо? Уж аргументы у меня всегда есть, толко я собеседником жалею, так как моя критика, как правила, очень жёсткая.

Жалеть не надо, в этом нет необходимости. А вот привести аргументы, которые будут небезосновательны, наверное стоит.

Если речь про ALT Linux, то правильнее было бы сделать модуль к Alterator. Это к вопросу о консистености пользовательского интерфейса.

Я пишу приложение пока только сам. Для внедрения в Alterator понадобится заниматься ещё и этим, т.е. помимо основной разработки. В конечном итоге, когда всё будет завершено, не мне решать "дотягивает" ли мой проект до необходимого уровня, достаточного для включения в Alterator. К тому же в Alterator уже есть менеджер пакетов. Именно по этим причинам данный код отделён.

Я не считаю, а предлагаю, как одну из мер. Перечитай мой пост внимательнее.

Заметил, но исправлять не стал, т.к. вопрос этот очень интересный. То есть, ты согласен с утверждением, что демонизацией должен быть усовершенствован именно apt-pkg?

[alexis031182]

Кстати, даже если досконально продумать и потом реализовать самый совершенный алгоритм получения метаданных пакетов, время, затрачиваемое на формирование списков этих самых метаданных, всё равно будет постепенно увеличиваться. Количество пакетов периодически растёт. Я так думаю, что 13000 штук из Сизифа - это далеко не предел. Отсюда само собой напрашивается вывод, что нет смысла в создании таких огромных списков для пользователя. Любой человек просто не в состоянии быстро просмотреть такую гору информации, да и не станет этого делать. Значит, информацию необходимо делить на части. На данный момент критерием деления выступают т.н. разделы или категории пакетов. Особо проблематичным разделом на мой взгляд является секция "Все пакеты", т.к. именно на её формирование расходуется большая часть времени при загрузке приложения. Есть предложение либо убрать совсем данную позицию, либо также разбить её на части, скажем, по алфавиту. Если это не устраивает, можно было бы, как вариант, визуализировать её постранично и показывать по 1000 (больше, меньше) штук пакетов на одной странице (как в виде "По группам"). Ещё можно попробовать сделать и так: все пакеты будут находиться в едином списке, в котором содержатся, сначала, только их наименования. При этом, остальные теги (например, версия, описание) будут появляться лишь для тех позиций пакетов, которые непосредственно видны в списке. Логическая оценка скорости обработки информации при данном подходе показывает, что результат будет выдаваться мгновенно. Единственным минусом выступает "скачкообразность" появления тегов, т.е. пользователь конечно заметит при быстрой прокрутке списка, что информация сначала отсутствует и только потом появляется.

Что думаете?

[Skull]

То есть, ты согласен с утверждением, что демонизацией должен быть усовершенствован именно apt-pkg?

Да, совершенно верно. Хотя это и не было сказано явно, за что прошу прощения.

[Skull]

сли это не устраивает, можно было бы, как вариант, визуализировать её постранично и показывать по 1000

Весь список четвёртого бранча (без номеров версий) занимает 756 кб. Это немного для Qt. Проблема в заливке текста в таблицу, так как получение через apt-cache занимает 3 секунды.

[alexis031182]

Весь список четвёртого бранча (без номеров версий) занимает 756 кб. Это немного для Qt. Проблема в заливке текста в таблицу, так как получение через apt-cache занимает 3 секунды.

Минимизировать время на просмотре пакетов через apt-pkg можно лишь ограничением читаемых тегов. Т.е. время на загрузку приложения пропорционально зависит от того, какое количество тегов (например наименование, версии, зависимости и т.д.) берётся из apt-pkg сразу же. Тут можно поступить так: читаем только наименования секций и самих пакетов, а визуальный список (Qt-виджет) сам "докачивает" всё остальное, но уже, естественно, не в таких объёмах и исключительно по необходимости.

[Skull]

Тут можно поступить так: читаем только наименования секций и самих пакетов, а визуальный список (Qt-виджет) сам "докачивает" всё остальное, но уже, естественно, не в таких объёмах и исключительно по необходимости.

Да, достаточно названий пакетов, версий и описаний. В принципе, можно докачивать по мере необходимости, начав с порции, влезающей на экран, как ты и предлагал выше. А уж дополнительную информацию — только при выборе пакета.

[alexis031182]

Вот ещё "немного" поработал над алгоритмом загрузки. Зацените скорость, особенно при повторном запуске приложения, когда apt-pkg уже всё закэшировал... ну... то что он там постоянно кэширует

ALLIGATOR (просто бинарник).

Работу по оптимизации продолжаю...

[Alexei_VM]

когда apt-pkg уже всё закэшировал... ну... то что он там постоянно кэширует

Ох, сдается мне, что apt-pkg НИЧЕГО не кэширует. Совсем. Ничего.

А просто в кэш в оперативке попадают файлы, к которым обращается apt, и повторное обращение происходит без чтения с диска.

[alexis031182]

Ох, сдается мне, что apt-pkg НИЧЕГО не кэширует. Совсем. Ничего.

А просто в кэш в оперативке попадают файлы, к которым обращается apt, и повторное обращение происходит без чтения с диска.

Самое интересное, что новый процесс кэширования начинается тогда, когда менеджер пакетов на некоторое время перестаёт выполнять свои непосредственные функции. У меня это, примерно, не более пяти минут. Если за это время ничего не делать (не устанавливать, не удалять, ну и прочее), то тот же Synaptic начинает снова "тупить", т.е. медленно формировать списки пакетов.