3 ms·

If you wanted a RPM that installs on multiple versions of RHEL, you would take the oldest RHEL you could find, build a rpm with all your dependencies except gli

If you wanted a RPM that installs on multiple versions of RHEL, you would take the oldest RHEL you could find, build a rpm with all your dependencies except glibc included, and ship that. The resulting rpm would work on all later versions of RHEL Problem is, you still need to update your dependencies, so sooner or later you’re bootstrapping modern GCC and Stdc++, openssl etc all from a Centos 5 base just to get a forwards compatible rpm A that point you start tarring up your chroots so you know how to reconstruct this Frankenstein build enviroment Thank Docker for giving an easily portable environment that’s almost as easily accepted by customers as a RPM

tuldia 7y ago
First you should not mix CentOS 5 packages into a CentOS 4 system. That is how you create a problem in the first place. Building software on top of frankenstein build environments is how you end with broken software, and should not be encouraged :) Let alone development environment.
- derefr 7y ago
  What the parent is describing by "Frankenstein build environment" is a bog-standard cross-compilation toolchain/SDK. You don't infect the host with the toolchain's packages; you install the toolchain's packages in the toolchain chroot. (If you've ever developed for an embedded arch, this will be painfully familiar.)
  - tuldia 7y ago
    > You don't infect the host with the toolchain's packages; you install the toolchain's packages in the toolchain chroot. Infect is a too strong word, because normally the cross compiler will coexist well with your system. But you are right about the chroot, throw it away and start again, repeat. That is great! I normally install gcc-arm-linux-gnueabihf + qemu-user-static and enable binfmt. It works well for building armhf, but I can imagine for things like ESP32 where you don't have the toolchain sources and etc.

tuldia 7y ago

First you should not mix CentOS 5 packages into a CentOS 4 system. That is how you create a problem in the first place. Building software on top of frankenstein build environments is how you end with broken software, and should not be encouraged :) Let alone development environment.

derefr 7y ago
What the parent is describing by "Frankenstein build environment" is a bog-standard cross-compilation toolchain/SDK. You don't infect the host with the toolchain's packages; you install the toolchain's packages in the toolchain chroot. (If you've ever developed for an embedded arch, this will be painfully familiar.)
- tuldia 7y ago
  > You don't infect the host with the toolchain's packages; you install the toolchain's packages in the toolchain chroot. Infect is a too strong word, because normally the cross compiler will coexist well with your system. But you are right about the chroot, throw it away and start again, repeat. That is great! I normally install gcc-arm-linux-gnueabihf + qemu-user-static and enable binfmt. It works well for building armhf, but I can imagine for things like ESP32 where you don't have the toolchain sources and etc.