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.

That sounds like a disaster waiting to happen... maintaining a different version of libraries outside of their main development trunk means that:

1. Extra steps when a new main version comes out - you have to repatch your differences in.

2. #1 incurs a delay, thus a longer time that your customer are running without patches, which may be a security issue.

3. You won't do #1 at all. Thus you become reliant on old, unmaintained, buggy, security-holey libraries.

The only time I can think this is acceptable is to fix problems that upstream won't fix, or are platform specific (ie, not with your custom software, but with the OS underneath everything).

Maybe 1.3 fixes a few bugs we haven't encountered yet. But that's unlikely. We've been using it for a year. Far more likely, as in practically a certainty, is that 1.3 will introduce some regression that won't be discovered until it affects some customer.

Not every bug in every program is a security vulnerability, and framing the issue that way distorts things.

It's just laziness. It's easier because that way you don't have to argue with Management. But you also don't educate on the necessity of fixing security issues. Hooray for 1.4 JVM still in production for instance. And it's perfectly ok. Until some breach happens .....

1. We have made changes to the 3rd party source code that we want to ship now, not when they finally let the patch into their source tree.

2. We get new updates from the latest release, patch in our stuff and we are set, quick test on the CI servers and we can ship. Yes, customers may be without the fix for a little while longer...

3. It is actually in our best interest to keep 3rd party libraries at their latest release, if we want secure software. Which is why it is part of our release documents and steps that are required to be followed before we release.

If you are expecting the person taking your patches to install them to the system, however, that's a whole 'nother ball game, and gets back to the original point: as a system administrator, I have no reason to believe your "better" versions of those libraries are going to interoperate with everything else on the system, and I am then going to have to do a bunch of work doing that isolation myself.

To make sure it compiles and works under dozen different distributions (in practice centos + ubuntu/debian usually cover most cases). If you don't test it, how do you know it's usable at all? Besides, as long as you don't invent some crazy custom build system, the only thing you really have to write is metadata and dependencies (rules file can be 3 lines long for autotools software).

Also, this way you can just push your software to a build farm like launchpad ppa and let them do the dirty work. If you include self-contained tests with the sources, you can even run them after the build to verify correctness for that environment. This is much better than doing it by hand.

Also keep in mind that the first person to deploy your software automatically to a couple of places will either use your/distro's package or will have to make their own. Building from source works only for one-person uncontrolled environment.

You have no idea how frustrating it is to have an open source project claim to run on unix like operating systems and not compile correctly on FreeBSD or Mac OS X...

Regarding FreeBSD... lack of any good result in the first 3 pages of "freebsd packaging guide" search should explain a lot.

But I understand your concern.

If I've written some software to scratch a personal itch and I push it out to github because I reckon someone, somewhere might benefit at some arbitrary future point, or to show off to a future employer, or whatever, then I really do not care about making sure it compiles and works on a dozen distributions. Just getting it working to fix my problem, then publishing it, ticks all the boxes I'm interested in. After all, I've got fifteen other problems I need to solve this week, none of which involve spooling up VMs for distributions I never use.

If a packager then decides that their favourite distro would benefit from having my code packaged nicely, at what point does that become my responsibility? It Works For Me(tm), and beyond reviewing and applying patches other people might send me to improve it, I don't necessarily have any interest whatsoever in what happens outside my repository as long as it doesn't stop the code from solving my problem. It's possible that I might be both developer and packager for a distribution or two, but that's the exception, not the rule.

Personally, I think the right way is for a clear path from language-package to distro-package to be provided by my environment such that I don't have to think about it, and I think that the bulk of that responsibility should be shouldered by the distro - but it's insane to think that the language environment shouldn't help, because there is a mutual benefit there. I think we're nearly there with RVM and rubygems, but that's about as far from autotools as you can get.

If you're in the enviable position of having lots of people willing to put in the time to maintain your package, and a distro that thinks your software is sufficiently noteworthy to include in their distro. But if your software is relatively new and you want to encourage wide adoption, one way to help is to make the install process friendly and familiar for sysadmins as well as fellow developers. And if you speak their language that goes a long way towards building that trust.

Agreed. I do, however, expect upstream to accept reasonable patches from package maintainers to fix building bugs or make it easier for people to build packages themselves.

For the few times I've done it, I've had no trouble getting upstream to accept an updated .spec file (or even a barebones .spec file) that they can distribute in their targz to make it easier for the people who want to build their software as a package if their distribution doesn't provide one.

It is 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.

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.

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.

You can't just write about the packaging process and hope people come forward to volunteer to do the actual work. There's a large amount of thankless sweat equity when you provide packages. People whine when things are broken and rarely send praise when it just works as it should.

If you really want to change the world, start with creating a Ruby apt repository for Debian/Ubuntu/whatever you use that people can actually deploy in production.

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 take away the gem command.

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.

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.

Is there anything wrong with this picture?

What I'm proposing is a full acknowledgement of that: if you want to live on the bleeding edge, then that should be supported as well as possible, but a very clear delineation should be drawn between the responsibilities of the distribution and those of the developer/sysadmin. RVM does that very cleanly, even if you only use it with the system ruby.

Might be better to un-gem any required gems and package them with the app. Then add some code that fakes out any calls in the app to 'gem' or 'rubygems'.

OTOH, rubygems is part of ruby now, so leaving it out might be a problem.

As far as calls to the "gem" method go, I have in mind a distro-specific replacement which would check that the right system package is installed instead of the right gem. That would, I think, be handy for packagers.

Having rubygems the library being part of ruby is not something I can see a problem with. Having the gem command available is a problem because it overlaps so much with functionality which should be provided by the distro. That being said, ~/.gem is useful; maybe it should only be neutered for root/sudo.

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.

That said, allowing user system wide installation could be possible. I think, at least under Linux, combining selinux and cgroup to provide sandboxed system wide user install could be possible but you'd possibly need to bypass classic unix directory ownership and permissions. That might require to much work or not even be impossible.

Anyone here with enough knowledge to confirm or refute my feeling ?

I also recommend checking out https://wiki.ubuntu.com/PbuilderHowto - pbuilder is "the" way to build packages, which I unfortunately discovered very late.

System packages just aren't what web savvy developers grew up on and the documentation feels out of step. But the capabilities and tools around system packages are awesome.

I might take a go a writing a simple guide, but I'd be more than happy to see other people have a go that know more than I do. Let me know if this sounds of interest.

It's also guilty of being unattractive to the developers I'd love to see use it. The site says "Recent News: Dec 26th, 2009" and then concentrates on a NOTE TO SLACKWARE 8.0 USERS.

Showing the hello world of checkinstall would be much better imho, and it's what developers from the web world expect.