It does. You can do crazy shit like this with Docker containers:
thinking about the time we created docker at work in 2009:
nobody could remake our centos4 build machine for our C++ code
so we shut it down, imaged the file system into a .tar.gz, and
made our makefiles transparently extract it & build via chroot.
so absolutely fucking cursed -- @stdlib
It's essentially still exactly what docker allows you to do:
tar-up your whole f'ing disk, and run it in a chroot somewhere else.
Of course it's horrible. But now, you can get away with it.
What has Docker to do with this?
It, well, I wrote a bunch of perl scripts to "streamline all life cycle commands across all services" back in 2002, where all we had were FreeBSD jails.
So, again, what's so special about Docker?
".. 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
Just a guess...
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
Building software on top of frankenstein build environments is how you end with broken software, and should not be encouraged :)
Let alone development environment.
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.
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.
What Docker did provide that other packaging tools didn't was free image hosting for anyone, no vetting, no strings attached. Of course that was a major hit with developers. Free hosting often is, especially when well integrated with development tooling.
The thing is that it sets you up for a nice acquisition. But for some reason Docker, Inc. felt they wanted to go the VMware Way instead and sell enterprise tools to enterprise customers. Those are two different strategies that will never be reconciled. It makes sense for them to shed that part and double down on Docker Hub and the Mac/Windows tooling.