История изменений
Исправление beck, (текущая версия) :
А вот у меня вопрос адептам двоично-бинарной совместимости.
Допустим есть у вас RHEL 8.4. и разработчики дали вам софт, собранный под 8.4.
Ну, ок, всё работает. Дальше в соответствии с порядком обновления ПО, принятым в организации, вы пишете dnf update, и… упс, RHEL уже не совсем 8.4. А через неделю оказывается, что 8.4 не соответствует уровню безопасности, принятому в организации, и нужно обновление до 8.5.
Ваш софт под всеми этими телодвижениями работает или ломается после первого же dnf update и вам необходимо каждый раз пересобирать его под каждый такой dnf update?
В моей практике использование RHEL регламентмровано только тем, что разработчик ПО при виде CentOS или Oracle Linux сразу шлёт лесом. Что касается конкретных версий, то времена, когда разработчики собирали ПО под совершенно определённые патч-левелы с конкретно описанными версиями пакетов прошли лет 15 назад. Теперь определяют только минимально допустимый минорный релиз, т.е. версия ОС не ниже RHEL 8.2 или AIX 7.2 TL05. Конкретные пакеты и обновления не важны.
Так вот. Зачем это бинарное дрочерство? Что оно вам даёт? Гарантию работы ПО? Нет, потому что ПО собиралось под 7.9, а у вас 8.4.
В чём именно проблема? Нужно именно такой патч-левел? Если у вас такая важная задача, то купите RHEL. Или соберите сами нужный вам уровень операционной системы.
Исправление beck, :
А вот у меня вопрос адептам двоично-бинарной совместимости.
Допустим есть у вас RHEL 8.4. и разработчики дали вам софт, собранный под 8.4.
Ну, ок, всё работает. Дальше в соответствии с порядком обновления ПО, принятым в организации, вы пишете dnf update, и… упс, RHEL уже не совсем 8.4. А через неделю оказывается, что 8.4 не соответствует уровнб безопасности, принятому в организации, и нужно обновление до 8.5.
Ваш софт под всеми этими телодвижениями работает или ломается после первого же dnf update и вам необходимо каждый раз пересобирать его под каждый такой dnf update?
В моей практике использование RHEL регламентмровано только тем, что разработчик ПО при виде CentOS или Oracle Linux сразу шлёт лесом. Чтт касается конкретных версий, то времена, когда разработчики собирали ПО под совершенно определённые патч-левелы с конкретно описанными версиями пакетов прошли лет 15 назад. Теперь определяют только минимально допустимый минорный релиз, т.е. версия ОС не ниже RHEL 8.2 или AIX 7.2 TL05. Конкретные пакеты и обновления не важны.
Так вот. Зачем это бинарное дрочерство? Что оно вам даёт? Гарантию работы ПО? Нет, потому что ПО собиралось под 7.9, а у вас 8.4.
В чём именно проблема? Нужно именно такой патч-левел? Если у вас такая важная задача, то купите RHEL. Или соберите сами нужный вам уровень операционной системы.
Исходная версия beck, :
А вот у меня вопрос адептам двоично-бинарной совместимости.
Допустим есть у вас RHEL 8.4. и разработчики дали вам софт, собранный под 8.4.
Ну, ок, всё работает. Дальше в соответствии с порядком обновления ПО, принятым в организации, вы пишете dnf update, и… упс, RHEL уже не совсем 8.4. А через неделю оказывается, что 8.4 не соответствует уровнб безопасности, принятому в организации, и нужно обновление до 8.5.
Ваш софт под всеми этими телодвижениями работает или ломается после первого же dnf update и вам необходимо каждый раз пересобирать его под каждый такой dnf update?
В моей практике использование RHEL регламентмровано только тем, что разработчик ПО при виде CentOS или Oracle Linux сразу шлёт лесом. Чтт касается конкретных версий, то времена, когда разработчики собирали ПО под совершенно определённые патч-левелы с конкретно описанными версиями пакетов прошли лет 15 назад. Теперь определяют только минимально допустимый минорный релиз, т.е. версия ОС не ниже RHEL 8.2 или AIX 7.2 TL05. Конкретные пакеты и обновления не важны.