Я бы хотел предложить сделать более сложный и функциональный бэкенд для работы с пакетами вместо текущей реализации если нет планов делать более низкоуровневую интеграцию с libapt За основу я бы взял https://github.com/alt-atomic/apm Какие приемущества это даёт : 1) JSON формат ответов 2) DBUS формат общения 3) Работа в режиме "демона", поддерживаются DBUS уведомления о каждой итерации внутри, в том числе о процессе загрузки файла и установки пакета (можно делать прогресс бары) 4) Предпросмотр установки/удаления пакетов, в удобном виде для фронтенда в формате JSON прилетают списки изменений которые показывает apt с флагом -s 5) Все ошибки apt "отлавливаются" и анализируются, с некоторыми из них бэкенд сам может справится, если ошибка критическая - она будет прилетать на фронтенд в удобном виде с учётом локализации 6) Внутри используется собственная база данных sqlite, это позволяет отображать весь список пакетов из репозитория, их зависимости и другую важную мета-информацию в обработанном виде без постоянных запросов к apt-cache и тд. 7) Благодаря собственной БД поиск/фильтрация/пагинация становятся тривиальной задачей для фронтенда и ускоряет эти операции на порядок 8) Есть интеграция с swcat для подтягивания иконок Это приблизительный список улучшений, в данный момент программа работает дополнительно с distrobox контейнерами, а так же умеет работать с атомарной системой и ALR но всё лишнее я конечно могу удалить и адаптировать под модуль альтератора
Подеержка e2k планируется?
(Ответ для Ivan A. Melnikov на комментарий #1) > Подеержка e2k планируется? Нативного backend’а для e2k в официальном Go нет. Зато можно запускать x86‑бинарь через встроенную двоичную трансляцию: CGO_ENABLED=0 GOOS=linux GOARCH=386 GO386=softfloat go build -o mytool - CGO_ENABLED=0 — убираем внешние зависимости - GO386=softfloat — выключачаем какие‑либо аппаратные инструкции В целом учитывая что самые тяжелый операции внутри - это внешние вызовы консольный команд вероятно это никак не скажется на работе. Но я никогда такого рода задачи не решал, недостаточно компетентен в этом вопросе, нужно изучать.
Вообще, варианты "более низкоуровневой интеграции с libapt" рассматриваются. Код apm нужно изучить. Функции, возможности, концепт. Бегло посмотрел. Не хотелось бы завязываться на парсинг строк apt-get. В худшем случае, давайте добавим в вывод apt-get дополнительные опции, чтобы получать на выходе ровно то, что требуется. Дальше-больше. Давайте просто приведём кодовую базу apt в порядок. ______ А вот собрать apm в сизиф не помешало бы, для начала. Собрал локально. Источники и количество зависимостей меня немного смутили. Как им дальше пользоваться - нужно разбираться: [sin@base build]$ ./apm s 2025/05/06 23:22:54 mkdir /var/local/apm: permission denied [sin@base build]$ ./apm -h 2025/05/06 23:23:04 mkdir /var/local/apm: permission denied [sin@base build]$ ls -l apm -rwxr-xr-x 1 sin domain users 23520504 мая 6 23:21 apm [sin@base build]$ ls -lh apm -rwxr-xr-x 1 sin domain users 23M мая 6 23:21 apm
(Ответ для Evgeny Sinelnikov на комментарий #3) > Вообще, варианты "более низкоуровневой интеграции с libapt" рассматриваются. > > Код apm нужно изучить. Функции, возможности, концепт. > > Бегло посмотрел. Не хотелось бы завязываться на парсинг строк apt-get. > В худшем случае, давайте добавим в вывод apt-get дополнительные опции, чтобы > получать на выходе ровно то, что требуется. > > Дальше-больше. Давайте просто приведём кодовую базу apt в порядок. > ______ > > А вот собрать apm в сизиф не помешало бы, для начала. > Собрал локально. Источники и количество зависимостей меня немного смутили. > > Как им дальше пользоваться - нужно разбираться: > > [sin@base build]$ ./apm s > 2025/05/06 23:22:54 mkdir /var/local/apm: permission denied > [sin@base build]$ ./apm -h > 2025/05/06 23:23:04 mkdir /var/local/apm: permission denied > > [sin@base build]$ ls -l apm > -rwxr-xr-x 1 sin domain users 23520504 мая 6 23:21 apm > [sin@base build]$ ls -lh apm > -rwxr-xr-x 1 sin domain users 23M мая 6 23:21 apm Зависимости Их число обусловленно количеством фич, там два типа хранения данных, TUI интерфейс для консольного диалога общения, цветной вывод, dbus, логи, работа с distrobox, podman, alr и прочее. Вероятно если это сокращать до одного простого модуля вместо комбайна - большинство функционала можно удалить и число зависимостей сократится Сборка В сизиф может быть соберёт Владимир (@rirusha) когда освободится. В документации есть простой bash скрипт установки либо пишите мне @dimcha_al - разберёмся. Работа Если не парсить apt-get - на что вообще фронтенд будет опираться при работе пока нет взаимодействия с libapt? Вывод в любом случае придётся парсить для приемлимого пользовательского опыта и понимания к чему приведут те или иные команды/действия Если в ближайшем будущем планируется тесная интеграция с libapt то вероятно смысла в этом предложении нет, можно закрыть тикет, это в любом случае лучше и открывает более широкии возможности, но смотря на текущую реализацию мне подумалось что я могу реиспользовать apm для расширения функционала альтератора.
