Comment by FooBarWidget | Hacker News Reader

Comment by FooBarWidget | Hacker News Reader

Parent Full thread

Creating proper platform-specific packages is a mad undertaking, requiring huge amounts of manpower to setup and to maintain. We provide native Phusion Passenger packages for 5 platforms (3 Ubuntu versions, 2 Debian versions, OS X Homebrew) and it's already crazy complicated. Check out the toolchain that we spent months on building:

https://github.com/phusion/passenger_apt_automation

https://github.com/phusion/passenger_autobuilder

And this is just one software package. Imagine at least 10 Ruby interpreters and versions (all versions of MRI 1.8, 1.9 and 2.0, all versions of Rubinius, all versions of JRuby). Now multiply that by the number of popular platforms. That's at least 13 (2 supported Ubuntu LTS versions, 1 latest Ubuntu non-LTS version, 2 supported Debian versions, latest 2 OS X versions, Windows, Red Hat, Fedora, CentOS, Arch, Gentoo). You'd end up with at least 100 different packages, and you'll have to test each one of them.

That's going to cost much more than a one-off campaign of $50000.

> Creating proper platform-specific packages is a mad undertaking, requiring huge amounts of manpower to setup and to maintain.

Of course you are right, and I am well aware of this. After all, that is the reason it has not been done before.

Still, a crazy amount of effort went into creating and maintaining rvm, rbenv and the myriad of other tools we now have. I cannot help but wonder where we would stand now had all of this instead been directed towards great packaging.

> You'd end up with at least 100 different packages, and you'll have to test each one of them. That's going to cost much more than a one-off campaign of $50000.

I am not quite so pessimistic. What I am daydreaming about would involve the distributions and their package maintainers. They already ship ruby right now. The packages are just not in optimal shape and oftentimes not up to date.

But one can surely build on the foundation already laid out by the distributions and work with them to hand off some of the work.

Still, I know this would be a herculean task. And not only a technical challenge, but a social one as well.

system packages and maintainers in current day are not used to support mixing multiple software with an easy separation like RVM does, they put everything in one prefix like /usr and change only application suffix, it works well with alternatives-update - but it’s static switching of ruby, what developers need is runtime switching and clear separation of libraries per language, the lack of clean separation also is bad when deploying servers that run multiple versions of given language (not limiting to ruby)

also check the update with schedule - https://www.bountysource.com/fundraisers/489-rvm-2-0 - "2 months: Work on building packages using RVM 2 (so it deprecates itself)"

Maybe that points to one source for the packages in many distros as the wrong way to go about it? You might be better off promoting a list of packages that repo maintainers (distro or secondary) could use to supply a well known set of ruby packages for a specific target. It's not like there's a shortage of people or institutions to do this if you make it easy for them.

Reply on news.ycombinator.com