Безопасно ли устанавливать собственные пакеты rpm в дистрибутивы на основе Debian?
У нас есть несколько серверов с Debian, Ubuntu и CentOS. Мы решили, что должны иметь возможность устанавливать наши собственные недвоичные и java-пакеты на любой из этих серверов, используя rpm, потому что CentOS - наш основной дистрибутив. Но в различных документах Debian можно найти много предупреждений об использовании rpm, и ни один из этих документов не раскрывает, что в этом плохого.
Что может пойти не так, если мы создадим наши собственные rpm-пакеты, содержащие только файлы .jar /.js, сценарии предварительной установки / пост-установки / запуска и без каких-либо зависимостей?
3 ответа
Это все причины, по которым я могу подумать, почему нельзя использовать пакеты, созданные для другого дистрибутива:
- Двоичные файлы могут быть созданы на основе библиотек, которые отсутствуют в текущем дистрибутиве или имеют неправильную версию.
- Расположение файловой системы может отличаться в разных дистрибутивах.
- другие предположения о системе, в которой устанавливается пакет, сделанные упаковщиком, которые могут не применяться в текущем дистрибутиве.
- Имена пакетов могут отличаться в разных дистрибутивах, поэтому зависимости могут не разрешаться должным образом.
- Специальные функции управления пакетами, такие как перехватчики и т. Д., Отличаются в разных менеджерах пакетов.
Если вы хорошо знаете об этом и знаете, что делаете, то использование RPM в Debian и Ubuntu не является проблемой.
В случае JS и Java без дополнительных зависимостей это не должно быть проблемой.
Без каких-либо зависимостей это может сработать, но я думаю, что вы вообще не используете пакет rpm. Просто скопируйте ваши сценарии, где вы хотите.
Также вы можете использовать конвертер для простого управления пакетами.
Я не думаю, что это хорошая идея, чтобы получить несколько систем управления пакетами в одной ОС.
Конвертер, он же инопланетянин, нестабилен и глючит.
Чтобы упаковать ваше программное обеспечение для другого менеджера пакетов, я настоятельно советую вам собирать из исходного кода такой инструмент, как fpm.
Не конвертируйте двоичные файлы для производственных серверов. Когда-либо. Вместо этого потратьте еще 1 час на правильную упаковку и избегайте долгой и скучной отладки.