Почему Installer-SH вне конкуренции среди способов распространения софта под Linux и FreeBSD

Это продолжение предыдущей статьи про работу над новой версией установочного пакета приложений под названием Installer-SH.

Ранее я поработал над удобством использования приложений в формате Installer-SH и протестировал установочный пакет. Я статически скомпилировал простую игру из исходного кода для максимальной совместимости с разными дистрибутивами Linux, так как распространяемые бинарные файлы в мире Linux оказались перегружены зависимостями и непригодны для распространения (типичный «ад зависимостей»).

Также в ходе сборки установочного пакета был выявлен незначительный недочет. При работе в режиме Tar (в отличие от 7-Zip) программа была недостаточно информативна во время упаковки архивов с использованием аргумента «apk». Я добавлю больше информации в вывод соответствующей функции, и на этом проблема будет решена.

Я разрабатываю Installer-SH самодостаточным и ориентированным на конечных пользователей, благодаря чему установка программ сводится к элементарному нажатию кнопки «далее» или запуску в тихом режиме, чтобы даже кнопку «далее» не нужно было нажимать. Однако к разработчикам у меня иной подход, и единственная инструкция по работе с форматом ориентирована на давно устаревшую версию 1.7.

Хотя про единственную инструкцию я слукавил, ведь Installer-SH разрабатывается по принципу самодостаточности и надёжности, поэтому основная инструкция находится не на виду, а прямо в теле установочного пакета. Разработчику достаточно открыть главный файл для настройки пакета, и всё самое важное окажется прямо перед глазами.

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

Тем более я не бросаю разработчиков один на один с пустым установочным пакетом. В каталоге installer-data есть все необходимые примеры, наглядно демонстрирующие, как всё работает. Даже не разбирающийся в программировании человек при желании сможет отредактировать конфигурационные файлы и подменить исполняемые файлы в каталоге самой программы, тем самым создав собственный установочный пакет. Нужно только желание и умение пользоваться «Блокнотом».

Ну а так как структура каталогов открыта для взаимодействия, а настройки хранятся буквально в текстовом виде, для разработчиков ПО нет никаких проблем создать свою систему автоматизации по настройке и упаковке приложений в формат Installer-SH. Разработчику достаточно просто поместить файлы программы в предназначенный для этого каталог и внести свои настройки в скрипты.

Но если честно, это звучит как глупость, потому что в реальности достаточно один раз вручную создать установочный пакет конкретной программы, а потом просто использовать его в качестве основы при выпуске новых версий ПО. Нужно просто сделать копию образца, заменить файлы программы на новую версию, изменить версию в настройках установочного пакета, чтобы она соответствовала программе, запустить ISH с аргументом apk, потом с аргументами clean и tarpack — всё, очередной распространяемый пакет готов. Это элементарные действия, выполняемые даже парой строчек самодельного Bash-скрипта.

Я же говорил про самодостаточность формата Installer-SH? В этом и заключается его самодостаточность: любое упакованное приложение в данном формате является полноценным носителем формата и может быть использовано для упаковки любых программ на основе уже существующих пакетов. Может быть, придётся найти архиватор 7-Zip под иную архитектуру, если использовался данный формат сжатия, а другая программа требует иную архитектуру, нежели исходная. Но это уже нюансы, без которых можно обойтись, перейдя на сжатие tar.xz.

Также не стоит забывать и про тот факт, что любая современная копия Installer-SH несёт в себе инструменты и базовые файлы, необходимые для подготовки основы по спецификации PortSoft и выделенного раздела меню в операционной системе для установленных приложений.

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

Можно ли воспроизвести репозиторий Debian или любой иной, вроде Flatpak или Snap, используя в качестве основы один сохранившийся пакет из репозитория? Однозначно невозможно. Даже просто сделать копию линуксоидного репозитория — это тот еще геморрой, не говоря уже о чем-либо другом.

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

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

Тем временем Installer-SH можно развернуть из любого старого установочного пакета в состояние, пригодное для упаковки новых программ. Главное, чтобы система соответствовала спецификациям XDG и содержала базовый набор инструментов вроде bash, sed, cp и тому подобных.

И тут возникает вопрос: а стоит ли вообще делать инструкцию для разработчиков? Когда-то в комментариях меня упрекали за её отсутствие, мол, разработчики якобы не могут разобраться в детально описанном самодостаточном скрипте... Но вот в чём проблема: в комментариях зачастую сидели тролли и просто хейтеры. Есть вероятность, что это были очередные недовольные пользователи из мира Linux, перед которыми стояла задача насолить мне — разработчику формата, не вписывающегося в привычный хаос и несостоятельность мира Linux.

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

Однако я всё же вижу один вариант, который действительно может помочь разработчикам, ранее не видевшим Installer-SH и желающим воспользоваться преимуществами самодостаточного и «неубиваемого» формата распространения ПО.

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

В итоге за вечер я набросал пошаговую инструкцию с примечаниями для разработчиков, которые понятия не имеют, как работать с Installer-SH. Также в начале отметил, что данная инструкция разработана для ручной упаковки программы. Если нужна полная автоматизация процесса — разрабатывайте свои скрипты, потому что нет единственно правильного способа это делать. Installer-SH и так автоматизирует огромную массу рутинной работы, и я не собираюсь затачивать формат под узкоспециализированные конвейеры сборки.

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

Ну а чтобы не быть голословным, давайте скомпилируем игру 2048 под FreeBSD и создадим новый пакет на основе старого, уже содержащего версию игры для Linux. Прежде всего распакую архив «program_files», чтобы получить доступ к файлам программы, и перепакую его уже со скомпилированной версией под FreeBSD.

Первым делом нужно скомпилировать игру из исходного кода в среде FreeBSD, и вот незадача: в очередном дистрибутиве отсутствует базовый компилятор GCC, как и в большинстве дистрибутивов Linux. По факту я не могу скомпилировать программу из-за характерной для Linux и FreeBSD функциональной ущербности. Это является проявлением феномена под названием «ад зависимостей», только в области распространения софта в виде исходного кода. Исходники есть, а скомпилировать невозможно, потому что вот так вот...

К счастью, компилятор GCC — настолько базовый и независимый инструмент, что он ничего не поломал в системе при установке из давно обновившихся репозиториев дистрибутива FreeBSD. Для понимания ситуации: у меня дистрибутив FreeBSD установлен уже давно, а репозитории за это время обновились несколько раз, если не десятки. Моя система буквально будет поломана, если я попытаюсь установить что-то, обременённое зависимостями из нового репозитория, предварительно не проведя полного обновления своей старой системы, что также сопряжено с риском всё поломать.

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

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

Статически скомпилированная версия игры под FreeBSD весит 3,6 мегабайта, что в пять раз больше, чем версия под Linux, но это разумная плата за независимость и совершенно не проблема, учитывая, что объёмы бюджетных HDD уже в 1999 году исчислялись гигабайтами.

Вот для примера: у меня есть на руках рабочий HDD Seagate ST34311A объёмом 4.3 гигабайта с датой выпуска 1999-07-27 (код 0004). Закончится ли у меня место, если я установлю на этот HDD десяток программ весом 3–4 мегабайта каждая? Конечно, нет. А больше люди обычно и не устанавливают для использования.

Скомпилированный бинарный файл для платформы FreeBSD перенёс, старый архив «program_files» удалил. Теперь можно приступать к упаковке нового установочного пакета игры «2048», используя в качестве основы старый, уже настроенный пакет от другой платформы.

Настраиваю главный скрипт, тут нужно сменить архитектуру для соответствия платформе FreeBSD и подправить описание.

Совсем забыл. Нужно ведь снизить размер словаря в настройках архиватора. Довольно глупо будет, если для распаковки программы весом в несколько мегабайт понадобится 64 мегабайта оперативной памяти. Нужно будет обновить уже собранный и загруженный недавно пакет игры под платформу Linux с оптимизированными параметрами сжатия, а то там всё было сжато со стандартными настройками.

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

Осталось протестировать собранный пакет в подходящем для него месте. Конечно, я могу установить пакет, предназначенный для FreeBSD, в среде Linux, но сама программа не запустится, если, конечно, у пользователя не установлен какой-то «франкенштейн» вместо операционной системы.

Не знаю, существуют ли такие гибриды Linux и FreeBSD, которые смогли бы запускать бинарные файлы обеих платформ, но мне было бы интересно на это посмотреть.

Изображение — Stable Diffusion.

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

При запуске через контекстное меню ярлыка окно терминала упорно отказывается открываться. Я даже вручную прописал параметр Terminal=true для каждого действия (Actions) в конфигурации ярлыка (что наглядно видно на скриншоте), но рабочее окружение операционной системы просто игнорирует эти инструкции.

Самое интересное, что этой проблеме подвержены как FreeBSD, так и многие дистрибутивы Linux. Это лишний раз доказывает, что даже при соблюдении всех официальных спецификаций Open-Source-разработчикам системного софта ещё есть над чем работать, чтобы пользователь не сталкивался с такими «сюрпризами» на ровном месте.

Ну а мне пора двигаться дальше. В итоге установочный пакет весит всего 970 килобайт благодаря сжатию архивов Installer-SH, и его по-прежнему можно распространять даже дискетами.

Осталось загрузить новый установочный пакет с игрой 2048 в репозиторий GitHub.

https://github.com/Shedou/Chimbalix-Software-Catalog

И тут я задумался: а можно ли сделать Installer-SH ещё более универсальным, чтобы он мог хранить и устанавливать мультиплатформенную версию игры? Звучит как вызов.

Ситуация действительно интересная, ведь разместить два исполняемых файла под разные платформы в одной папке совершенно несложно.

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

Можно было переписать логику работы с исполняемым файлом, но я просто создал две переменные, указывающие на бинарники разных архитектур, и условие, учитывающее архитектуру системы. Мне не пришлось вносить серьёзные изменения в лаунчер: просто подставляю путь к нужному исполняемому файлу в зависимости от архитектуры. Вроде мелочь, но она доказывает, что Installer-SH — не только надёжный и практичный, но и весьма гибкий инструмент, способный решать весьма специфические задачи.

Хоть один линуксоидный пакетный менеджер или формат распространения софта для Linux, которыми порой гордятся разработчики дистрибутивов, способен на такую гибкость и жизнеспособность, какую продолжает демонстрировать Installer-SH? Вопрос, конечно же, риторический.

Изображение — Stable Diffusion.

Ладно, повеселились — и хватит. Доработать лаунчер для корректного выбора исполняемого файла в зависимости от архитектуры было легко. Теперь нужно что-то придумать с главным скриптом, который не рассчитан на одновременную работу с двумя разными платформами. Попробую для эксперимента указать обобщенный тип платформы x64.

Теперь нужно отключить предупреждение о несоответствии архитектуры. Так как пакет экспериментальный, я не вношу исправления в основную версию проекта. Но, может быть, если этот эксперимент пройдёт успешно и докажет на практике пользу от мультиплатформенных установочных пакетов, я смогу внести эти улучшения в основную версию Installer-SH, сделав его ещё более универсальным и недосягаемым для прочих способов распространения ПО.

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

Устанавливаем игру под управлением Linux.

Всё отлично установилось и работает.

Устанавливаю игру тем же установочным пакетом под управлением FreeBSD, и снова всё проходит отлично. Игра установлена и прекрасно работает. Эксперимент завершился успешно. Теперь у меня есть единый установочный пакет Installer-SH с игрой 2048 для двух разных платформ одновременно. 

Да, мультиплатформенный пакет с игрой весит целых 1,2 мегабайта, но, если посчитать, можно заметить, что два пакета с этой же игрой по отдельности имеют общий размер в 1,4 мегабайта. Так что мы даже сэкономили место за счёт более эффективного сжатия файлов для двух разных платформ в едином архиве, чем если бы они были разбиты на два отдельных пакета.

Это достойно того, чтобы создать раздел мультиплатформенных установочных пакетов в репозитории Chimbalix-Software-Catalog.

То, что я лёгким движением руки смог создать мультиплатформенный установочный пакет, который автоматически выбирает нужную версию программы для запуска в зависимости от платформы, лишний раз доказывает: Installer-SH находится не просто вне конкуренции среди способов распространения софта для Linux и FreeBSD, а стоит на порядок выше.

На этом можно завершить работу над новой версией Installer-SH и сделать релиз.

Найти Installer-SH можно в репозитории GitHub: https://github.com/Shedou/Installer-SH.

На этом можно завершить статью. И так объём материала вышел больше ожидаемого, зато удалось довести новую версию установочного пакета Installer-SH до очередного выпуска. Изменений и улучшений получилось не слишком много, но они серьёзно улучшили пользовательский опыт и техническую сторону установочного пакета, а это достойная причина для выпуска.

Благодарю за внимание, больше интересных статей в блоге Hard-Workshop.