упаковка в стандартные пакеты пакетного менеджера выбранного дистрибутива GNU/Linux - единственно верный гетеросексуальный белый цисгендерный путь.

У эрланга свои релизы есть, докер тоже норм в зависимости от инфраструктуры, у нас все на докере - и даже тесты в женкинсе.

упаковка в стандартные пакеты пакетного менеджера выбранного дистрибутива GNU/Linux - единственно верный гетеросексуальный белый цисгендерный путь

Да вообще ни разу. Вот релизнется CentOS 8, опять сломают макросы в RPM, и что тогда? Опять две версии спеки держать и костыли делать? Нет уж, лесом-лесом.

как будто это сложно

ну или объявить в таком случае centos 7 деприкейтнутным и настоятельно рекомендовать клиентам обновиться до 8

У эрланга свои релизы есть

Есть, но там с версиями слегка проблема. Безболезненно откатиться нельзя, если я правильно помню.

докер тоже норм в зависимости от инфраструктуры, у нас все на докере - и даже тесты в женкинсе.

Вот я тоже к этому склоняюсь: собирать в CI образ и через Ansible обновлять его. Но вдруг есть настоящий путь джедая?

Это несложно, но это лишний геморрой, от которого я хочу избавиться.

Админы напирают на Docker, но я слегка сомневаюсь.

Это единственный правильный способ деплоя программ сейчас.

Я пакую в deb пакеты, например.

Удваиваю докер.

упаковка в стандартные пакеты пакетного менеджера выбранного дистрибутива GNU/Linux - единственно верный гетеросексуальный белый цисгендерный путь.

плюсую.

лишний геморрой, от которого я хочу избавиться.

имхо получишь ещё больше, но в другом месте.

имхо получишь ещё больше, но в другом месте.

В каком? Пока у rpm сплошные минусы. rpm-build — это вообще хтоническая срань. Хуже этого только сборка пакетов у дебиана, из-за которой вон уже мейнтейнеры бегут из дистра.

К сожалению, докер — полная дрянь, но большинство альтернатив ещё хуже.

У меня была мысль использовать Nix, но в нашу инфраструктуру его встроить будет весьма непросто. Докер здесь выигрывает.

Быдлокодер детектед :)

Из личного опыта вынес четыре подхода: пакеты, устанавливаемые системным менеджером пакетов (rpm/deb); эрланговые релизы; докер; тарболл с прилагой, который раскатывается в ~/app, при этом используется системный эрланг/epmd.

Будто бы что-то плохое.

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

Вот релизнется ...

Апдейтов бояться - софт не писать. Совсем как банковский кредит — берешь и потом тратишься на сопровождение, пока не умрёт.

Гм... У меня нет кредитов. Видимо, с CentOS так же стоит поступить.

Какой смысл в отдельном образе с энларгом? Разве у BEAM между релизами гарантируется бинарная совместимость?

Ну да, я из-за rpmbuild свалил на арч в 2006м. Но я бы не ожидал от других решений чего-то сильно лучшего.

энларге

гомосексуальным

И тут пришёл поручик...

так же стоит поступить

«Стоит» - категория арифметическая. Некоторым людям кредиты выгодны, некоторым - нет, и, думается, разница не в кредитах.

да, нормуль.

Админы непонятно чего лезут в бутылку. Если хотят докер, то пусть берут твой rpm и ставят его в свой докер.

Можно конечно отказаться от rpm и сменить на deb, но это чаще всего бывает завязано на эмоциональную привязанность команды. Мы, например, предпочитаем deb.

Админы напирают на Docker, но я слегка сомневаюсь.

А какие у них доказательства^Wаргументы?

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

У нас заворачиваются в deb пакеты, но там исходники, сборка происходит при развёртке на целевой машине

Javascript?

javascript для чего?

Если модуль вебовский, то там будут куски javascript или шаблоны html, все они при сборке тупо идут в priv директорию соответствующей зависимости.

Сборку делает модифицированный rebar из шаблонного Makefile, postinst написан на обычном bash с вызовами стандартных awk, sed, make, зачем тебе javascript?

Я имел ввиду что у вас так разворачивается приложение на JS. Просто встречал такие предложения от JS-разрабов: а давайте мы на проде sudo npm install и запустим.

А какие у них доказательства^Wаргументы?

Отсутствие геморроя с конфликтами зависимостей как минимум.

Админы непонятно чего лезут в бутылку. Если хотят докер, то пусть берут твой rpm и ставят его в свой докер.

Тогда нахрен нужен rpm, если докер умеет версионирование?

Можно конечно отказаться от rpm и сменить на deb, но это чаще всего бывает завязано на эмоциональную привязанность команды. Мы, например, предпочитаем deb.

Deb как формат пакетов ещё хуже.

ну если админы напирают и желают, так напряги их на демонстрацию. тогда и будет видно, удобно ли это, выдерживает ли это обновление beam, удобно ли это в разработке?
у нас специально на докер не переползали, но в процессе ci-cd на серверах он появился и снял вопросы с деплоем. но у нас jar'ки и всё просто.

похоже на какую-то дичь
а зачем так?

Докер с эрлангом не надо собирать, они уже собраны: https://github.com/erlang/docker-erlang-otp

deb собирается штатными линуксовыми утилитами и имеет внутри понятную человеческую структуру.

rpm как формат — самое худшее, что есть на планете. Это я говорю как один из тех, наверное, 10 людей на планете, кто писал бинарный парсер/упаковщик формата rpm пакета.

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

Чего там хорошего в операционках, которые им пользуются, я не знаю.

deb собирается штатными линуксовыми утилитами и имеет внутри понятную человеческую структуру.
rpm как формат — самое худшее, что есть на планете

Как пользователю, мне наплевать. Собирать deb с помощью tar и ar всё равно никто не будет. Утилиты для сборки deb ни разу не лучше, чем rpmbuild.

Это я говорю как один из тех, наверное, 10 людей на планете, кто писал бинарный парсер/упаковщик формата rpm пакета.

Крайне сомнительный повод для гордости.