The current situation w/ homebrewn installers is really ugly - see tons of forum posts.
We have decent package management technologies like APT, which industry-grade proven for over two decades, that handles all the usual aspects of software deployment - downloads, installations, dependency management, fully automatic upgrades, inventory, clean removal, etc, etc. This also includes post-installation steps like database updates, automatically building OOT kernel modules, etc. Such technology has also been ported to esoteric and very operator-unfriendly platforms like Windows.
The key point here is the Distribution: software has to be compiled and packaged for a particular distribution and target architecture, so everything (including ABIs) really fit together and the software is neatly integrated into the ecosystem.
There are two major package manager stacks: dpkg/apt and rpm/yum, each used for dozens of different distros/platforms. Once the build process is set up (est. just several man-days initially), dozens of distros can be easily supported w/ neglectable effort. With an CI, the whole build/packaging/deployment process can easily run completely automatically.
Once packages are available that way, operators just have to add the vendor's package repository once to their system and then everything - including updates - can run automatically. Operators also can easily mirror repos, eg. for offline deployment, additional QA+approval, etc.
Since 20+ years there is no need for homebrewn installers whatsoever. They're just an extreme waste of resources - on both vendor and user side.
Properly packaging directly to certain distros and using only the native package managers for deployment would make the tons of operating/deployment problems (as seen here in the forum) go away - they're basically but problems w/ the distro-incompatible homebewn installers.
--mtx
Linux Embedded / Kernel Hacker / BSP / Driver development / Systems engineering
