Отсутствие нужных пакетов для библиотек предотвращает создание пакетов для прикладных программ. Именно из-за этого нельзя просто взять и написать apt-get install discourse
Хотя вообще-то для этого всё есть. Я имею в виду, что существуют правила для создания пакетов для web-приложений, соглашения по их установке в конкретном дистрибутиве (хотя соглашения по размещению директорий разные например в Debian и в Gentoo).
У некоторых пакетных менеджеров есть скрытые бонусы, например:
создание резервных копий исходных текстов для всего установленного ПО. Конечно это сомнительное преимущество, но чем больше самостоятельности, тем лучше.
цифровые подписи для пакетов собранных бинарно, гарантии мейнтейнеров, воспроизводимые сборки. Наличие ответственности и возможности её разделения позволяет лучше объединять усилия разных людей.
возможность оживления пакета в случае полной смены команды разработчиков. Этим хорош и знаменит проект Apache с его процедурой перемещения проектов в Attic и обратно.
Конечно, у разных пакетных менеджеров свои модели. Это означает, что надо проводить работу по унификации подходов, выделению общих понятий в библиотеки, а форматов в стандарты. А не создавать каждый раз новый менеджер, как только ты сделал свой отдельный язык программирования. Не было бы ничего плохого, если бы такие менеджеры опирались на фиксированные форматы, но вместо этого некоторые (такие как gem) в качестве синтаксиса используют синтаксис конкретного языка программирования (в случае gem - ruby)!
Есть две идеи как с этим бороться:
делать пятнадцатую реализацию пакетного менеджера, зато своего
делать метамодель и систему типа gptchat, чтобы она умела подстраиваться под любой пакетный менеджер.
А с библиотеками дело не только в наличии пакетов. Если у каждого юзера будут свои версии библиотек (+ вышеперечисленного) в зависимости от ОС сервера, то это добавит проблем тех. поддержке. Не говоря уж о том, что надо будет делать пакеты для десятка ОС.
Поэтому оф. способ – докер. Скачал, отредактировал конфиг, запустил, и всё.
Не надо смешивать установку и настройку.
Пройдёмся конкретно - Apache/NGinx (это “вебсервер”) вполне себе УСТАНАВЛИВАЮТСЯ пакетным менеджером ОСи.
БД, почта, certbot - тоже.
Что такое “очереди” я не знаю.
То есть, задача установки для всех них решена. Значит можно решить и задачу установки web-приложения через пакетный менеджер операционной системы.
А настройки можно сделать чем-то ещё, утилитами для каждого из продуктов. a2ensite например есть для Debian, но нет аналога для Gentoo
Выполнение фоновых задач, в данном случае sidekiq.
Так дело в том, что этот продукт делался не только для бородатых админов генту. Большинству было бы сложно правильно настроить это всё, так как нужно дискорсу.
Всё равно они провалили задачу, потому что не сделали для flatpak, snap, appimage, qemu iso и что ещё там бывает для абстрагирования от пакетных менеджеров.
Это вместо того, чтобы включиться в работу по стандартизации.
Но докер же и стал стандартом для распространения подобных серверных штук.
Заодно еще и кроссплатформенным, вдруг найдутся любители виндосерверов.
qemu это вм и производительность вроде должна быть хуже линуксового докера.
А остальные флатпаки и снапы не могут решить задачу по связыванию всех этих разных сервисов из коробки.
