AppImage Hub — каталог, который проверяет приложения за вас

Обычно, чтобы попасть в каталог софта, нужно заполнить форму, приложить скриншоты, описание, иконку, список зависимостей. Здесь всё иначе. Вы открываете ссылку, создаёте файл, пишете в него одну строку с адресом репозитория и отправляете пул-реквест. Всё. Через пару минут бот сам скачает вашу сборку, запустит её в виртуальной машине и выложит скриншот главного окна прямо в комментарии к PR.

Мне это показалось настолько необычным, что я полез разбираться, как такое вообще возможно.

Что за проект и зачем он нужен

appimage.github.io — это краудсорсинговый каталог AppImage-приложений. Не магазин, не репозиторий с файлами, а именно справочник: здесь лежат ссылки на страницы авторов плюс метаданные, которые автоматика вытащила из самих сборок.

Ключевая идея простая. Вся информация о приложении и так путешествует внутри AppImage: desktop-файл, иконка, AppStream-метаинфо. Значит, не нужно спрашивать автора о версии, лицензии и названии — надо просто дать каталогу адрес, а дальше он разберётся сам.

Кому это выгодно? Разработчику — он становится заметнее для тех, кто ищет софт в формате AppImage. Пользователю — появляется единое место, где видно, что вообще существует. А авторам софтверных центров — готовый источник данных, не нужно ползать по интернету и собирать ссылки вручную.

Как добавить приложение

Создаёте файл по этой ссылке и пишете туда одну строку — ссылку на GitHub, Codeberg или GitLab репозиторий с AppImage в релизах. Можно указать директорию загрузок, например https://download.kde.org/stable/digikam/, или адрес конкретного файла.

Дальше начинаются строгости. Пул-реквест обязан менять ровно один файл в data/. Одно приложение — один PR. Нарушили правило, тест упадёт и повесит метку error-filename.

Имя файла тоже подчиняется правилам:

• название приложения как в desktop-файле, например data/Krita
• пробелы заменяются на _, как в data/Linux_Device_Manager
• без версии, архитектуры и расширений: не data/App-1.0-x86_64.AppImage
• регистр важен, App и app — разные вещи

Идеальный вариант — ссылка на страницу проекта, а не на конкретный файл. Тогда тест возьмёт сборку из самого свежего релиза, выберет x86_64, отбросит debug и nightly-сборки. Если в релизе лежат два похожих AppImage, например App-qt5-x86_64.AppImage и App-qt6-x86_64.AppImage, тест не станет угадывать и попросит указать файл явно.

Что проверяет автоматика

Вот это самая интересная часть. GitHub Actions не просто проверяет ссылку на доступность, а реально запускает приложение.

Сборка должна скачиваться через wget. Приложения за авторизацией и куками не подойдут, поэтому для коммерческого софта советуют выкладывать общедоступную trial-версию. Формат — type 2 с файловой системой SquashFS. DwarFS, который используют uruntime и quick-sharun, пока не поддерживается: тест не умеет его монтировать.

Дальше список требований, который объясняет, почему в каталоге относительно немного приложений:

• запуск на самой старой из поддерживаемых LTS-версий Ubuntu без доустановки пакетов
• работа в тестовом окружении на GitHub Actions
• поддержка X11, тестов для Wayland нет
• прохождение appdir-lint.sh и desktop-file-validate
• работа без интернета, хотя бы с показом какой-то информации
• появление главного окна за 30 секунд, причём окно не должно быть пустым или с ошибкой

Отдельно отмечу пункт про отсутствие сети. Электронным приложениям авторы README даже подкидывают готовый сниппет: проверяем доступность сети и либо грузим основной URL, либо локальную страницу offline.html.

(async () => {
  if (await isOnline() === true) {
    mainWindow.loadURL(HermesURL);
  } else {
    mainWindow.loadFile('offline.html')
  }
  mainWindow.maximize();
  mainWindow.show();
})();

Если тест упал, в PR прилетит комментарий с описанием ошибки и подсказками. Поправили релиз — пишете /retest или просто сообщаете, что проблема решена. Автоматика запустится снова.

Хочу предупредить: каталог ничего не гарантирует. Проверяют соответствие базовым соглашениям AppImage и запуск на старой LTS-версии Ubuntu. Всё. Запускать скачанный софт стоит только от авторов, которым доверяете, и наличие записи в каталоге само по себе доверием не является.

Как забрать данные

Для софтверных центров есть JSON-фид на https://appimage.github.io/feed.json. Формат пока не финализирован и может меняться без предупреждения, о чём авторы честно пишут в README. Если данных не хватает, предлагают написать в IRC на #AppImage и обсудить нужную структуру.

Уже сейчас этим фидом пользуются несколько проектов: lliurex-store, aipm, chob, nx-software-center, appimagepool, appcenter, spm и страница AppImages на software.manjaro.org. Список открытый, свой проект можно добавить пул-реквестом.

Стоит ли связываться

Проект живёт с 2017 года, набрал около 400 звёзд и 800 форков. Цифры скромные, но за ними стоит важная деталь: почти тысяча форков при 400 звёздах означает, что люди приходят сюда не «звёздочку поставить», а отправить своё приложение. И больше пяти тысяч открытых issues — это в основном автоматические отчёты о том, что сборка по ссылке пропала. Полезная штука, хотя выглядит пугающе.

Что мне нравится: низкий порог входа для автора. Одна строка, дальше всё делает бот, включая скриншот для страницы. Такой подход экономит время и снимает с мейнтейнеров ручную проверку.

Что смущает: README местами сухой и требует внимательного чтения. Часть правил спрятана в деталях, а провалившийся тест не всегда очевидно объясняет, что именно не так. Если вы собираете AppImage с нестандартной структурой, будьте готовы к нескольким итерациям.

Кому заходить в первую очередь:

1. Авторам AppImage-приложений — добавьте проект в data/, это займёт пять минут.
2. Разработчикам софтверных центров и лаунчеров — забирайте feed.json, вместо того чтобы парсить сайты авторов.
3. Тем, кто выбирает дистрибутивы для тестов — пригодится как источник живых примеров корректно собранных AppImage.

Начать проще всего с самого каталога: найдите своё приложение, посмотрите, как выглядит карточка, и сравните с требованиями из README. Разница между «работает у меня» и «работает в каталоге» обычно и есть весь список проверок.