I have never shipped unix software that used the system package manager, for a number of reasons. If you want it to be cross platform, you need to build/test/ship the fallback tgz manual install anyway. Packages don't save any work, they only increase the size of your build farm and testing matrix. The software was usually built against specific versions (often modified) of 3rd party libraries. We can't rely on the system to have them, so we need to ship them too, so it's not like relying on system packages would reduce our download size at all. All told, the number of customers who care is very small, either because people just don't care or because the people who care don't pay for software.<p>That was for commercial software of course, but even for open source software, I'm not sure why it's the author's responsibility to go setup a dozen different VMs. That really is the package maintainer's job.
I consider it a significant black mark on a product, open source or otherwise, if it doesn't have native packages for the most popular Linux distros. It's even better if they provide a yum or apt repository.<p>It <i>is</i> a challenge to do so, but if we can do it for our products (which have vast and complicated dependency chains and need to perform a huge amount of post-configuration in order to be easy for non-technical users to use), damned near any other project ought to be able to do it.<p>The vast majority of really ugly security issues I've seen have been due to people having installed something from source, sometimes years ago, and not realizing they're running exploitable software because their package manager tells them they're up to date. This reason alone should be enough to keep people using the native package manager for as much as possible. But there are many other good reasons, a few of which have been touched on in this article.
Your post boils down to something like "developers should ship Debian packages because I use Debian and all my favorite software packages are out of date or non-existent".<p>Maybe you should move away from a distro that freezes for 6 months to roll a stable release which won't get anything more than security/crash fixes for 2+ years.
For my money, here's what needs to happen (from a Ruby perspective; salt to taste):<p>1. Debian and Ubuntu stop packaging any Ruby libraries which aren't dependencies of an actual end-user application. If rubygems itself is a library dependency, package it but <i>take away the gem command</i>.<p>2. Make a public policy saying "If you want to do development, use RVM," and have metapackages with the dependencies for building each RVM ruby (so ruby-dev-mri, ruby-dev-jruby, and so on). Make sure that users know that if they think they need to run "gem install foo", then they need RVM.<p>It'd be nice for RVM to be able to build system packages, but I don't think it's necessary: there are already systems (nascent, but improving) for converting gems to system packages which handle dependencies nicely.<p>Is there anything wrong with this picture?
One of the reasons software gets released in scripts rather than packages is because the root package installation mechanism is root accessible only. Most companies restrict root access and package installation is blocked by proxies. The combination of which means that scripts that can be downloaded separately and run are much easier for enterprise developers to use and get started with.<p>Until the average enterprise realises that packaging and installation needs to be done better we will always have the need for mechanisms that hack around the problem that system admins cause for the users of the servers.
Is there a decently written guide for creating ubuntu packages? The package maintainers guide confuses the heck out of me and it's way too long and disorganized.