Казалось бы, в современном Linux благодаря стандартам freedesktop можно просто взять и собрать кросс-дистрибутивный пакет для любого графического приложения, который будет располагаться в хомяке и таскать с собой все нужные библиотеки.
Делается это так:
- .desktop кладём в ~/.local/share/applications
- иконку к .desktop кладём в ~/.local/share/icons
- приложение и его библиотеки кладём в ~/.local/share/$VENDOR/$APP
- типовой shell-скрипт с LD_LIBRARY_PATH кладём в ~/bin
- приложение пишется так, чтобы не мусорить в хомяк и использовать /tmp, XDG_DATA_DIR, XDG_CONFIG_DIR
И всё работает, и любая DE видит эту программу, и пользователи плачут от радости.
Но не тут-то было. Потому что в Linux нет API с обратной бинарной совместимостью. Потому что LSB — лживый недостандарт, предназначенный исключительно для подсаживания дурачков на вендорную иглу и сколачивания бабла (Ульрих Дреппер, бывший лидер проекта GLIBC, писал об этом ещё в 2005-м; я проверил ситуацию пару дней назад — и увидел, что LSB dll hell проявится даже в таких «правильных» дистрибутивах, как OpenSUSE).
А как бы всё-таки мог выглядеть этот API, который должен быть на любом CD с любым дистрибутивом и должен появляться сразу после установки в любом дистрибутиве? Тут три критерия: минималистичность, привлечение разработчиков с других платформ и самодостаточность.
По моим современным личным представлениям, любая библиотека в идеале выполняет ровно одну из двух задач: предоставляет API или является фреймворком. Библиотека-API минималистична и массштабируема, но требует знания матчасти и множественных проверок кодов возврата: на ней можно написать быстрый и качественный движок (графический, звуковой, рендеринг шрифтов), но использовать такое в приложении напрямую без обёрток может только недалёкий человек. Библиотека-фреймворк, напротив, выполняет общие задачи не задаваясь максимальной гибкостью, но зато с удобством; при этом фреймворк должен либо иметь обратную бинарную совместимость в течение многих лет, либо его надо встраивать в пакет с приложением; примером первого подхода является Qt, примером второго - cocos2d-x.
Исходя из этих представлений, я вижу так:
- Linux API должен иметь два слоя: первым будет максимально привлекательный фреймворк с обратной совместимостью, вторым будет набор кроссплатформенных массштабируемых сишных библиотек с максимальной гибкостью и производительностью.
- Первым слоем должен быть Qt5 — программы на нём практически не требуют дополнительных библиотек и легко переносимы на Windows, OSX (а теперь отчасти и на android с iOS). Вкупе с поддержкой QML и javascript это будет сильнее всего привлекать людей к разработке и портированию качественных приложений для/на Linux.
- Вторым слоем должен быть набор библиотек, позволяющих общаться с любой важной внешней сущностью. Шрифты, работа с OpenGL, создание окна и контекста OpenGL, работа со звуковыми устройствами, открытие URL по клику и вывод уведомлений — все эти штуки приложение не сможет нормально сделать само или с помощью библиотек в своём пакете. Это должен быть внешний API.
- Во второй слой точно должны попасть: OpenGL, OpenAL, fontconfig и freetype. Библиотеки png и jpeg попадать не обязаны — да, они часто используются, но они не работают с внешней средой и легко могут быть в составе пакета приложения. Надо также разработать библиотеки (а не утилиты командной строки и не dbus-интерфейсы) для работы с DE (appmenu, прогрессбар и badges на иконке приложения в лаунчере, уведомления)
- За размер пакетов бояться не стоит: zip и bz2 очень хорошо жмут бинарники, link-time optimization и strip вырезают из них лишнее, а наличие Qt5 в первом слое API уже даст кучу крайне лёгких Qt-приложений для узких задач, более опытные и уверенные в себе разработчики смогут сделать относительно лёгкое приложение на втором слое API.
Какие ещё библиотеки должны попасть во второй слой API? И может быть, я что-то упустил из виду?
P.S. Генту идёт в лес. Если вы готовы собирать то же приложение из исходников или оптимизируете работу сервера — флаг вам в руке, но о готовых пакетах с десктопными приложениями забудьте, сами же отказались от этого в своей идеологии.
