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

Ну..это можно использовать как пинг, когда не имеешь морального права трогать сотрудника. В отпуске, к примеру.

Это вопрос выделенного на это времени

В целом я понял, это не расценивают как проблему. Все просто согласятся и все.

ну правильно, вы же описываете именно ту проблематику, вокруг которой выросло явление и движение devops

Конечно же девелопер может написать скрипт, который пакует софт в пакет, ставит его и делает что-то ещё.

Но когда девелопер в этом не участвует, когда этим занимается «билд инженер» (офигеть, целая штатная единица на то, что делается один раз и больше не нужно возвращаться!), то девелоперы будут делать то, что плохо пакуется, а «билд инженер» будет требовать то, что тяжело напрогать

Еще лучше профильный чат по обслуживанию сервиса. Если жертва не отписалась на отпуск оттуда, то можно написать: -«Ну все, не ясно теперь что делать. Только если бы %username% зашел поглядел - он бы тогда понял как решить»

Если девелопер не в состоянии асилить стнтаксис specfile или debian/rules, это плохой, негодный девелопер. Его срок годности истёк и его надо выбросить

Осилить синтаксис рулесов несложно (тем более что это шелловый скрипт), гораздо сложнее сделать приличный пакет в соответствии с правилами дистрибутива. Это не только спека, это еще и херова гора всего с зависимостями, версионированием и так далее.

Нет. В 2021-м году все run-зависимости проставляются автоматом.

Версионирование делается ОДНОЙ строчкой.
В RPM добавляются epoch и release, но если программер ниасилил эти сущности, он имбецилен

Нет :) Вернее как — да, debhelper тебе впишет зависимости от библиотек, с которыми оно собралось. Но если ты не понимаешь, что делаешь, то все это рано или поздно сломается при апгрейде зависимых пакетов. И это только библиотеки, остальные зависимости сами не впишутся. Плюс надо понимать, что тебе не впишут, что тебе дистрибутив гарантирует, что нет, какие зависимости у тебя слабые типа Recommends и так далее.

Вообще, это хороший тест на программиста линупс: спросить про смысл какой-нибудь конструкции типа install -m 0644.....

Но я соглашусь, что в целом это не очень сложная деятельность, если речь про несколько пакетов. Дистрибутив в целом это непросто.

Рекоммендс не нужны для подавляющего количества софта. Как и Провайдс.

Да кому это нужно с проприетарным софтом?!


Мы пакуем вообще все кроме glibc в /opt/flussonic и я не вижу ни единой причины не делать так

С проприетарным -- никакой. Если, конечно, вы тащите все свое с собой.

поддержу.
обычно вместе с этим идет позиция "это не мое дело, я код закоммитил"

Ну или если очень хочется так не делать, то ci, 9 образов под все варианты и пачка артефактов.

Но это опять же: тикет девелоперу а не билд инженер.


Но под винду все плохо, это факт.

билд-инженер (а точнее, 3 ШЕ, потому что кто-то более, кто-то в отпуск идет) появляется, когда это окупается, имхо.
достаточно специфичные условия поставки - если вы какой-нибудь Canonical или Acronis

Поясни пожалуйста. Может я чего-то не знаю, зачем он там нужен?