3 ms·

Excuse me but this is "crazy shit": ".. in 2009: nobody could remake our centos4 build machine for our C++ code ... so absolutely fucking cursed" What le

by tuldia 7y ago

Excuse me but this is "crazy shit": ".. in 2009: nobody could remake our centos4 build machine for our C++ code ... so absolutely fucking cursed" What lead a computer running a supported operating system[1] in a state like this? Distill that and you have docker :) 1. https://en.wikipedia.org/wiki/CentOS#End-of-support_schedule https://en.wikipedia.org/wiki/CentOS#End-of-support_schedule

heinrichhartman 7y ago
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. Just a guess...
- unilynx 7y ago
  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
  > 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.

by tuldia 7y ago

heinrichhartman 7y ago

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. Just a guess...

unilynx 7y ago
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
> 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.