To avoid the XY problem, let me first describe the situation.
We have a client project of unique circumstances. We have a relatively modern software stack (Keras DNN stuff) that needs to run on a client's system. This system, a Cloudera CentOS 6 cluster, in production, is airgapped for security. We can't guarantee this thing has ever seen the internet, ever.
We developed a bash script which installs the requisite packages from disk using RPM and tested on our local simulated (containerized) cluster (YUM fails because the repo database is not up to date). After some fiddling, we were able to get Keras running without so much as a packet from the internet.
The client has his own virtualized system set up which is supposed to be pretty close to the actual cluster (in terms of config). When he ran it, however, total catastrophe. Lots of errors like:
(for installing glibc-common-2.12 and friends via
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
(Or running the command: 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 is needed by Y is the most common error, but we also see ones like
openssl < 1:1.0.1-0.3.beta3 is obsoleted by (installed) openssl-libs-1:1.0.1e-42.el4.9x86_64
and
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
In particular, a lot of conflicts are stemming from
- libc.so.6
- libm.so.6
- libgmp.so.3
- libmpfr.so.4
- libstdc++.so.6
- libffi.so.6
which are all super crucial libraries, and I 1) can't assume any particular version will be on the cluster, and 2) can't be monkeying around with, lest one of them breaks.
I'm more of a machine learning CS and my linux skills are enough to set up and service CUDA boxes and such, but this is starting to be deep water for me, so any input, even simple stuff, is appreciated. Is there any way to create a separate library environment where we can install the necessary deps without disturbing the ones already there? I know chroot
is a thing but I have no idea how to properly wield it.
tl;dr - dependency hell on an airgapped system with no remote admin ability and a crusty old, poorly-maintained build.
Many thanks!