> A single package, for a single package manager that runs everywhere and is tightly integrated with the language, is the only reasonable solution.
Well yeah if your product is uni-language. If it is not then you are installing python pips, ruby gems, java jars, make && make installs for C++ code. And some stuff is uni-language, granted. A lot of Github demo projects and libraries are uni-langue And then they might have cross-dependencies, some have transitive dependencies. And you might have to uninstall some old package and install new one, except you can't make make & make install just dumps files on the file system and doesn't know how to properly clean up after itself.
Then in many cases uni-platform is common. That calls for using the OS package manager. Say if your services sit on tops of CentOS 6.5 then why run around sprinkling files all over the file systems via shell scripts or re-implement an adhoc package manager in bash when you can just use RPMs.
I have seen this all too many time "RPM writers are stupid, look at this complexity, I'll do it quicker". In the end they come up with something messier, less reliable, not-quite-working-right re-implementation of RPMs.
Well yeah if your product is uni-language. If it is not then you are installing python pips, ruby gems, java jars, make && make installs for C++ code. And some stuff is uni-language, granted. A lot of Github demo projects and libraries are uni-langue And then they might have cross-dependencies, some have transitive dependencies. And you might have to uninstall some old package and install new one, except you can't make make & make install just dumps files on the file system and doesn't know how to properly clean up after itself.
Then in many cases uni-platform is common. That calls for using the OS package manager. Say if your services sit on tops of CentOS 6.5 then why run around sprinkling files all over the file systems via shell scripts or re-implement an adhoc package manager in bash when you can just use RPMs.
I have seen this all too many time "RPM writers are stupid, look at this complexity, I'll do it quicker". In the end they come up with something messier, less reliable, not-quite-working-right re-implementation of RPMs.