Установка RPM в системе без интернета вызывает конфликты зависимостей: libstdc ++. So.6, libm и т. Д.

Чтобы избежать проблемы XY, позвольте мне сначала описать ситуацию.

У нас есть клиентский проект с уникальными обстоятельствами. У нас есть относительно современный программный стек (материал Keras DNN), который необходимо запускать в системе клиента. Эта система, кластер Cloudera CentOS 6, находящаяся в производстве, закрыта для обеспечения безопасности. Мы не можем гарантировать, что эту вещь когда-либо видели в Интернете.

Мы разработали сценарий bash, который устанавливает необходимые пакеты с диска с помощью RPM, и протестировал его на нашем локальном смоделированном (контейнерном) кластере (YUM не работает, потому что база данных репо не обновлена). После некоторой игры мы смогли запустить Keras без каких-либо пакетов из Интернета.

У клиента настроена собственная виртуализированная система, которая должна быть довольно близка к реальному кластеру (с точки зрения конфигурации). Однако, когда он его запустил, полная катастрофа. Множество ошибок, например:

(для установки glibc-common-2.12 и друзей через sudo rpm -Uvh glibc-common-2.12-1.209.el6_9.1.x86_64.rpm glibc-2.12-1.209.el6_9.1.x86_64.rpm glibc-headers-2.12-1.209.el6_9.1.x86_64.rpm glibc-devel-2.12-1.209.el6_9.1.x86_64.rpm )

warning: ./rpm/glibc-common-2.12-1.209.el6_9.1.x86_64.rpm: Header V3 RSA/SHA1 Signature, key ID c105b9de: NOKEY
error: Failed dependencies
    tzdata >= 2015g-4 is needed by glibc-common-2.12-1.209.el6_9.1.x86_64.rpm
    libc.so.6(GLIBC_2.13)(64bit) is needed by (installed) util-linux-2.23.2-26.el7.x86_64
    libc.so.6(GLIBC_2.13)(64bit) is needed by (installed) systemd-219-19.el7.x86_64
    ...(more of the same)...
    libc.so.6(GLIBC_2.13)(64bit) is needed by (installed) xz-libs-5.1.2-12alpha.el17.x86_64

(Или выполните команду: sudo rpm -Uvh gcc-c++-4.4.7-18.el6.x86_64.rpm gcc-4.4.7-18.el6.x86_64.rpm libstdc++-4.4.7-18.el6.x86_64.rpm libstdc++-devel-4.4.7-18.el6.x86_64.rpm )

libstdc++.so.6(GLIBCXX_3.4.15)(64bit) is needed by (installed) {name of a package}
libstdc++.so.6(GLIBCXX_3.4.15)(64bit) is needed by (installed) {name of another package}
...

X нужен для Y - самая распространенная ошибка, но мы также видим такие, как

openssl < 1:1.0.1-0.3.beta3 is obsoleted by (installed) openssl-libs-1:1.0.1e-42.el4.9x86_64

и

file /etc/rpm/macros.ghc-srpm from install of epel-release-6-8.noarch conflicts with file from package redhad-rpm-config-9.1.0-68.el7.centos.noarch

В частности, много конфликтов проистекает из

• libc.so.6
• libm.so.6
• libgmp.so.3
• libmpfr.so.4
• libstdc ++. so.6
• libffi.so.6

которые все являются суперкритическими библиотеками, и я 1) не могу предположить, что какая-то конкретная версия будет в кластере, и 2) не могу возиться с ними, чтобы одна из них не сломалась.

Я больше занимаюсь машинным обучением, и моих навыков работы с Linux достаточно, чтобы настраивать и обслуживать блоки CUDA и тому подобное, но это становится для меня глубокой водой, поэтому любой ввод, даже простой, приветствуется. Есть ли способ создать отдельную библиотечную среду, в которой мы можем установить необходимые приложения, не нарушая уже существующие? Я знаю chroot это вещь, но я понятия не имею, как правильно ею владеть.

tl; dr - ад зависимостей от системы с воздушной заслонкой, без возможности удаленного администрирования и корявой старой, плохо обслуживаемой сборки.

Большое спасибо!