Укрощение зависимостей в Linux: 10 лет истории Krita в одном пакете Installer-SH

Оглавление

• Оглавление
   
• Вступление
   
• Графический редактор Krita
   
• Почему исходный код мёртв
   
• Несостоятельность Flatpak и Snap
   
• Installer-SH и сбор информации
   
• Очередные проблемы формата AppImage
   
• Первый пакет в формате Installer-SH
   
• Новые проблемы AppImage и Krita
   
• Эксперименты со сжатием
   
• Ад зависимостей
   
• Проблема актуальных версий Krita
   
• Почему Krita зависает при первом запуске
   
• Коллекция в формате Installer-SH
   
• Тестирование (Debian 7, Fedora 20 и прочие)
   
• Тестирование (openSUSE)
   
• Тестирование и костыли (Debian, Fedora, Manjaro)
   
• Installer-SH успешно поглощает прочие форматы
   
• Проверка совместимости и эксперименты
   
• Утерянные дистрибутивы
   
• Результаты и заключение

Вступление

Недавно была доработана, протестирована и выпущена релизная версия Installer-SH 2.8 — перспективного формата распространения ПО для Linux и FreeBSD. Также был выпущен первый установочный пакет с игрой «2048» в данном формате, который успешно прошёл тестирование в разнообразных дистрибутивах Linux и FreeBSD.

Как можно заметить из итогов тестирования, только Installer-SH смог доставить игру пользователям разнообразных дистрибутивов Linux и FreeBSD. AppImage заработал лишь в двух случаях из восьми. Ну а прочие пакетные менеджеры, вроде APT, Flatpak и Snap, полностью провалились как способы распространения ПО, буквально превратившись в бесполезный цифровой мусор при попытке воспользоваться ими в условиях, приближённых к реальности.

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

В плане работы без root-прав и простоты получения для офлайн-использования, дела обстоят хорошо только у форматов Installer-SH и AppImage. Но вот с зависимостями, интеграцией и прочими параметрами у AppImage всё плохо. Про пакетные менеджеры, окрасившиеся в красно-желтые цвета, и говорить нечего.

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

Но мне это даже на руку: ведь пока формат свежий и неизвестный, я могу спокойно его совершенствовать и оттачивать в реальных условиях использования. Хотя первый установочный пакет новой версии формата был мультиплатформенным и мультиархитектурным, следующий будет предназначен только для Linux. Это обусловлено рядом факторов, о которых мы ещё поговорим.

Графический редактор Krita

Для дальнейших экспериментов возьмем известный графический редактор Krita. В целом, я не знаю ничего лучше для замены всем известного Photoshop в среде Linux. Но у данной программы, как и у большинства других для Linux, есть серьёзный изъян который препятствует свободному распространению и использованию этого мощного графического редактора.

Любители Linux наверное думают, что если напишут словосочетание «свободное и открытое ПО» в описании своей программы, то она автоматически становится свободной. Нет. Это так не работает. Можно сколько угодно писать про свободу и открытость, но если программу невозможно по-человечески скомпилировать и распространить, то ни о какой свободе речи быть не может.

Проблема графического редактора Krita в том, что он распространяется через пакетные менеджеры вроде Snap и Flatpak, абсолютно непригодные для использования в автономном режиме. Также эти пакетные менеджеры крайне требовательны и зависят от конкретных версий дистрибутивов Linux. В общем, он распространяется с помощью несвободных и несостоятельных форматов в среде Linux.

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

Почему исходный код мёртв

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

           

Фактически, разработчики графического редактора установили тотальную монополию на компиляцию своей программы из исходного кода, так как ни один обычный пользователь не сможет просто взять проект в виде исходников и независимо скомпилировать его, получив рабочую программу. Для компиляции нужно собрать огромный набор зависимостей и специфических инструментов, что практически невозможно для обычного пользователя ПК.

Я даже брал исходники графического редактора Krita из репозиториев Debian, чтобы скомпилировать их. В теории, это самый лёгкий способ собрать что-то из исходного кода, потому что костыли уже все заготовлены и обкатаны людьми, заведующими репозиторием. Как вы думаете, оно скомпилировалось? А вот и нет.

Компиляция оборвалась в середине процесса, с ошибками. Что-то она там не нашла в каталоге с исходниками программы. Krita вызывает уважение как графический редактор, но разрабатывается этот проект крайне плохо. Его просто невозможно собрать простой компиляцией из исходного кода.

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

Несостоятельность Flatpak и Snap

Конечно, можно попробовать выдернуть исполняемые файлы и зависимости из репозитория Snap, но там в наличии лишь одна версия программы, и та — уже устаревшая.

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

           

На официальном сайте Flathub пишут про размер скачивания всего в 250 мегабайт, но в реальности это лукавство репозитория Flatpak. Помимо самой программы, придётся скачать порядка 1200–1300 мегабайт зависимостей, только под одну операционную систему. На других операционных системах и конфигурациях ПК набор зависимостей будет иным. Это одна из причин, почему я такого плохого мнения о формате распространения ПО под названием Flatpak.

Помимо скачивания гигабайтов рантаймов (KDE/GTK-платформ), Flatpak полностью изолирует приложение в «песочнице», из-за чего усложняются банальный экспорт файлов, подключение специфических планшетов или кастомных плагинов, если не ковырять разрешения через сторонний Flatseal.

Installer-SH и сбор информации

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

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

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

Изменяю формат сжатия на гораздо более эффективный 7-Zip, так как хочу не только улучшить пользовательский опыт при установке программы, но и существенно сэкономить место на диске при хранении установочных пакетов графического редактора. Сейчас нам не нужна мультиплатформенность, поэтому нет никаких проблем в использовании архиватора 7-Zip.

Таким образом была создана заготовка. Именно её я буду использовать в качестве основы при подготовке каждого пакета в отдельности. Можно, конечно, просто распаковать образы AppImage и бездумно разбросать файлы, но это подход линуксоидов. Я же хочу убедиться, что каждый пакет работает правильно. Installer-SH без проблем установит каждую из версий, но будет ли сама программа работать без дополнительных «костылей»?

Очередные проблемы формата AppImage

Вот, кстати, и очередная проблема формата AppImage: программы в старом формате невозможно распаковать, используя актуальные аргументы запуска. Придётся потанцевать с бубном. Ничего не поделать. Linux не имел бы плохой репутации, если бы подобные проблемы не возникали на каждом углу. Да и не пришлось бы мне разрабатывать свой формат распространения ПО, если бы линуксоидные форматы были пригодны для нормального использования.

К сожалению, вменяемых способов распаковать AppImage старого типа не нашлось, но, к счастью, архиватор 7-Zip оказался способен распотрошить данный контейнер. Хотя делает он это неправильно, так что продолжаем танцы с бубном.

Пришлось вручную смонтировать контейнер в файловую систему через терминал, чтобы всё правильно извлечь, не повредив исполняемые файлы.

На всякий случай проверил работоспособность оригинального контейнера AppImage, запустив Krita 3.0.94. Каким-то чудом не произошло серьёзных конфликтов файлов конфигурации, несмотря на то что у меня уже были устаревшие конфиги, от другой версии программы в домашнем каталоге.

Осталось перенести файлы в нужный каталог. Скорость доступа к содержимому контейнера AppImage довольно печальна (всего 6–14 МБ/с), учитывая, что работа производится на NVMe SSD Samsung 970 PRO. Это, собственно, ещё одна проблема контейнерных форматов вроде AppImage и причина моей нелюбви к таким способам распространения софта.

Первый пакет в формате Installer-SH

Первый установочный пакет готов.

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

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

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

Новые проблемы AppImage и Krita

Дошла очередь до Krita 4.0.4, и тут контейнер AppImage существенно изменился, так что старые методы монтирования больше не работают. Что же, нам не привыкать к танцам с бубном в Linux.

Эта версия программы не запускается корректно после распаковки контейнера AppImage.

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

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

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

Я могу прописать костыли в свой лаунчер в составе Installer-SH для корректного запуска программы. Или даже просто подсунуть AppRun-файл из набора AppImageKit, чтобы он сам «потанцевал с бубном» при запуске кривой программы. Но исправить откровенно побитый файл, запускающийся с ошибкой «Segmentation fault», не в моих силах.

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

Эксперименты со сжатием

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

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

Ад зависимостей

Krita 5.2.16 уже начинает демонстрировать явление под названием «ад зависимостей», да не абы каких, а самых базовых, системных, вроде libstdc++.so. Вот это уже интересно, потому что в оригинальном формате AppImage есть костыль для подмены версии библиотеки.

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

Радует, что над установочными пакетами формата Installer-SH можно работать одновременно, без конфликтов. Вот так, параллельно архивирую два разных пакета с помощью одной команды.

Проблема актуальных версий Krita

Krita 5.3.1 удивила меня своей крайне долгой загрузкой. Опять наступил на последствия ужасной культуры разработки данного проекта?

Увы, мы снова имеем дело с некомпетентностью разработчиков проекта. Нам, судя по всему, попалась сломанная версия графического редактора. Она виснет на этапе загрузки ресурсов, постепенно съедая оперативную память. И не стыдно разработчикам такие релизы выпускать? Где тщательное тестирование проекта после компиляции и сборки? Почему такие серьёзные проблемы обнаруживаю я, обычный пользователь?

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

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

Это фиаско. Krita 5.3.2 оказалась такой же поломанной, как и 5.3.1. Неважно, запускаю ли я её в виде официального AppImage-пакета или как распакованную программу.

Решил подождать до последнего. Минут пять, наверное, ждал. В итоге Krita запустилась, но израсходовала внушительные 1.6 гигабайта оперативной памяти. Я не знаю, в чём проблема, но в этом явно виноваты разработчики ПО. Старые версии работали намного быстрее и потребляли меньше оперативной памяти. Могу лишь предположить, что переделали что-то, связанное с чтением установленных в системе шрифтов (у меня их много), и сделали это не очень грамотно. Радует, что это «мракобесие» происходит только один раз, при первом запуске, а повторные запуски проходят нормально.

Почему Krita зависает при первом запуске

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

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

Позже, раскопав каталоги, я подтвердил свою догадку: дело в большом количестве шрифтов. Был обнаружен файл базы данных SQLite объемом 215 мегабайт, в котором закэшировано более 3700 шрифтов, установленных в моей системе. Именно на создание этой базы данных, современные версии графического редактора Krita тратят так много ресурсов и времени. Уже предвкушаю будущие конфликты из-за подобных файлов баз данных, если запускать их без изоляции со стороны Installer-SH. Остальным придётся надеяться, что разработчикам хватит ума присвоить уникальные имена подобным файлам, как только они нарушат совместимость с уже выпущенными программами.

Коллекция в формате Installer-SH

На этом основные пакеты собраны и проверены в пределах дистрибутива Chimbalix. Но есть кое-что, что хотелось бы реализовать. Это не входит в стандартный функционал формата Installer-SH, однако никто не запрещает мне собрать единый набор из тринадцати версий Krita за целых 10 лет выпуска.

У меня уже подготовлены тринадцать установочных пакетов; задача сводится к тому, чтобы объединить файлы всех программ в один пакет, а уже готовые — очистить от мусора и упаковать в распространяемый tar-формат. Благодаря проработанности формата Installer-SH мне достаточно ввести две команды для завершения упаковки. Если бы я проводил чистку вручную, то наверняка со временем где-то ошибся бы и удалил лишнее.

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

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

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

И нет, вы не ослышались: тринадцать упакованных версий Krita в формате Installer-SH весят около 740 мегабайт. Для сравнения, эти же файлы в оригинальном формате AppImage весят два с половиной гигабайта.

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

           

Первый блин вышел комом. Оно и неудивительно, ведь делаю такое впервые. Но страшного тут ничего нет: массивный архив перепаковывать не придётся, потому что проблема в ярлыках, а они находятся в отдельном архиве «system_files». Я просто забыл исправить имена лаунчеров в путях к исполняемым файлам.

Обновляю файлы и переустанавливаю программу поверх уже установленной. Так сказать, выполняю обновление.

           

Теперь всё установилось правильно. Именно этот набор мы будем тестировать на совместимость в разных дистрибутивах Linux, так как я понятия не имею, какова совместимость у этого графического редактора. Данную информацию, по-хорошему, обязаны предоставить разработчики ПО, но в Linux вечно всё сделано как попало, поэтому буду сам выяснять нюансы. А потом, линуксоидные разработчики искренне не понимают, почему в desktop-сегменте доминируют Windows и macOS, а Linux считается чем-то неполноценным и проблемным.

Тестирование (Debian 7, Fedora 20 и прочие)

Начинаем тестирование с дистрибутива Debian 7. Так как система работает в Live CD-режиме, я думал предварительно использовать скрипт из комплекта Installer-SH для создания RAM-диска в ОЗУ под каталог PortSoft. Но Debian 7 выделяет почти 8 гигабайт для файловой системы при 16 доступных, поэтому устанавливаю просто так.

                       

Самые старые версии Krita 3.x отлично запустились и заработали в столь старом дистрибутиве Linux. Это радует. Но вот четвёртая версия уже требует GLIBC 2.17 или выше для запуска. И да, устанавливал набор прямо с CD-ROM диска.

                       

Аналогично провожу тестирование в дистрибутиве Fedora 20. Только на этот раз создаю RAM-диск в оперативной памяти, ибо Fedora выделяет меньше гигабайта под файловую систему, и если всё заполнить, то система сломается в буквальном смысле.

                       

В Fedora 20 заработали версии графического редактора 4.0.4 и 4.1.7 в дополнение к ветке третьих версий. Неплохо. В остальных случаях Installer-SH информирует пользователя об ошибке при запуске ПО.

           

Тестирование (openSUSE)

Следующим подопытным оказался openSUSE 13.1. К сожалению, графический редактор не запустился в данном специфическом дистрибутиве Linux. Вероятно, он слишком стар для этого.

                                   

А потом посмотрел хронологию версий openSUSE и офигел от того, что после 13.2 идёт 42.1, а после 42.3 следует 15.0. Вроде и интересный дистрибутив Linux, но брать такой в тестирование очень сомнительно, ибо возникнет серьёзная путаница. Это сработает, только если переназначить версии в адекватном порядке вместо официального.

На всякий случай протестировал openSUSE 13.2: он 2014 года выпуска, намного новее Debian 7 и Fedora 20. Но Krita всё равно не запустилась в этом дистрибутиве Linux. Мне даже интересно стало.

                                   

Дистрибутив openSUSE Leap 15 уже справился с запуском старых версий софта, но всплыла очень странная проблема.

                                   

Ярлыки в меню приложений ну никак не хотят работать. Даже принудительное обновление меню через терминал не помогает: он только ругается на встроенные «из коробки» ярлыки дистрибутива, которые криво настроены, например, org.kde.systemmonitor.desktop.

                       

Мне так и не удалось выяснить, в чём проблема с ярлыками. Тем более что игра «2048» прекрасно запускалась из меню приложений теми же ярлыками. Даже не знаю, стоит ли добавлять openSUSE в список совместимых платформ. Формально программа работает, начиная с 15-й версии дистрибутива, но это очень странно. Похоже на проблему операционной системы или рабочего окружения KDE.

Я уже пожалел, что взялся тестировать столь специфичный Linux. Но дело нужно завершить, поэтому напоследок проверяю openSUSE Leap 15.5. Здесь уже нет проблем с запуском ПО через ярлыки в меню приложений.

                       

В целом, какие-то версии Krita запускаются, а какие-то — нет. Очень странный этот Linux.

                                   

Интересно, насколько нужно не любить пользователей своего дистрибутива, чтобы так сильно ломать ранее прекрасно работавшие вещи в системе. Наверное, это известно только разработчикам дистрибутива openSUSE.

                       

Извините, но настолько нестабильный и поломанный дистрибутив, как openSUSE, я не буду вносить в список совместимости. Я отказываюсь поддерживать это кривое мракобесие. Пусть мой Installer-SH работает даже в настолько поломанном ужасе, но заниматься поддержкой нестабильной ОС просто глупо. Любые уважающие себя разработчики дистрибутивов Linux стараются сохранить совместимость со старым софтом, разработчики же openSUSE, судя по всему, плевать хотели на какую-либо совместимость.

Тестирование и костыли (Debian, Fedora, Manjaro)

Лучше вернусь к тестированию Debian и Fedora, а потом возьму Manjaro для разнообразия. Это будут три основные, но разные ветки развития дистрибутивов Linux.

           

Среди интересного было обнаружено: начиная с Debian 11 графический редактор ветки 3.x вылетает с ошибкой при первом запуске, но последующие запуски проходят отлично. Не знаю, что изменилось в «чистых» Debian 11 и 12, что первый запуск старых версий ПО приводит к аварийному завершению, которое отлавливается лаунчером Installer-SH. Но это забавный нюанс и очередное подтверждение того, что в Linux вечно всё работает как попало.

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

                       

Придется поработать над собственными «костылями» и перепаковать уже созданные архивы. Иначе, из этого характерного для Linux ада не выбраться. А ведь так не хотелось городить десятиэтажные «костыли» в лаунчере. Вот и понадеялся на хваленый AppImage: мол, правильный бинарник всё сделает сам. Ничего он сам не сделал — пришлось вносить «костыли» в лаунчер формата Installer-SH, чтобы грамотно запустить изначально плохо разработанную линуксоидную программу.

Теперь оно работает не хуже оригинального контейнера, так как я успешно воссоздал скрытые от пользователя «костыли», необходимые для правильного запуска приложения. Осталось внести эти «костыли» в остальные пакеты и протестировать заново на совместимость.

Installer-SH успешно поглощает прочие форматы

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

Успешно запускаю весь набор Krita за десять лет разработки в основной операционной системе. Как там поживают пакетные менеджеры вроде APT, Flatpak и Snap? Вопрос, конечно, глупый, потому что пакетные менеджеры не способны на такое. Там просто недоступно такое разнообразие версий графического редактора Krita, не говоря уже об установке хотя бы двух разных версий одновременно, без конфликтов.

Проверка совместимости и эксперименты

Начинаю проверку совместимости в дистрибутиве Debian 7. Постепенно буду переходить к более новым версиям и вносить результаты в установочные пакеты. Также пройдусь по дистрибутивам Fedora и Manjaro. Хотя я и воссоздал «костыли» оригинального контейнера AppImage, полностью побороть «ад зависимостей» это не позволяет. Увы. Тут только компилировать программу с нуля, собрав все зависимости вместе, но это невозможно, так как культура разработки программы Krita очень плоха.

Однако совместимость действительно улучшилась при использовании «костылей», но только до тех пор, пока не потребовалась GLIBC более свежей версии, чем установленная в системе.

Ради интереса я подсунул GLIBC более свежей версии и программа даже почти запустилась, но что-то не срослось, и она упала с ошибкой «Segmentation fault». Теоретически я мог бы потанцевать с бубном ещё больше и расширить совместимость программы сверх официальной за счёт собственных «костылей». Но, боюсь, я и так слишком много танцевал с бубном. И да, исходный AppImage точно так же обламывается на зависимостях, даже не показав окно загрузки, в отличие от того, что у меня получилось.

Удивительно, но Manjaro 20+ оказались не способны запустить программу Krita 3.x, даже в виде исходного контейнера AppImage.

Утерянные дистрибутивы

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

Но в какой-то момент разработчики дистрибутива Manjaro удалили все старые образы операционной системы из централизованного репозитория, и огромная масса ссылок по всему интернету оказалась недействительной. А кроме ссылок и наивной веры в то, что репозитории будут жить вечно, линуксоиды ничего, собственно, и не имели. Вот вам и хваленая долговечность цифровых дистрибутивов: в один клик админы стирают историю ОС, оставляя пользователей с мертвыми .torrent-файлами.

Не удивлюсь, если точно так-же исчезнут и прочие образы дистрибутива Manjaro по вине ненадёжности и непостоянности централизованных репозиториев.

Самое старое, что удалось найти — это Manjaro 17.1.1 в веб-архиве, а нужно гораздо более старое. Да и те, кто сталкивался с веб-архивом, знают, что наличие файла ещё не означает его доступность. Хорошо, если скорость скачивания окажется выше 300 килобайт в секунду.

В общем, я был прав насчёт старых версий дистрибутива Linux. В Manjaro 17.1.1 версии графического редактора 3.x и 4.x отлично запустились. В Manjaro 20+ версия 3.x не запускается. Опять что-то поломали с обновлениями. Ох уж этот Linux.

Придётся указать совместимость некоторых пакетов: что-то вроде «Debian 7 или выше, а Manjaro — до 19-й версии и ниже». Звучит абсурдно, но таков Linux.

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

Результаты и заключение

Что тут у нас? Всё верно: чем новее программа, тем хуже совместимость. Особняком стоят «кривые» дистрибутивы Manjaro и openSUSE. И да, Debian 11 я не включал в таблицу, так как там ситуация аналогична Debian 10. Также не включал в сравнение бета-версию графического редактора, ибо она не входит в 10-летний набор размером всего 737 МБ, по сравнению с 2,5 ГБ официальных AppImage-контейнеров.

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

Ну а я на этом закончу. Готовые установочные пакеты графического редактора Krita можно найти в репозитории Chimbalix-Software-Catalog, а также, где угодно в интернете или на локальных носителях, если пакеты будут распространяться другими пользователями. Хотя, учитывая, что у Linux очень мало пользователей, рассчитывать на других людей не приходится.

https://github.com/Shedou/Chimbalix-Software-Catalog/releases/tag/krita3456collection

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

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

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