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

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.

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.)

> 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.

> Most likely, custom installed libraries and tools (./configure; make; make install), that were never packaged. And a package manager, that can't even tell you if any of the installed files were changed, after they were installed.

Software has to be read or at least installed in a safe place (before installing on a live server) so then one can be sure it does nothing silly.

Packaging is not hard, but there are some rules, including placing binaries in /usr/bin, configuration files in /etc and /etc/default (deb) or /etc/sysconfig (rpm), general package files in /usr/share. If you place files in the standard locations probably the package manager will detect changes in config files.