RubyGem is from Mars, AptGet is from Venus

Posted by Pelle December 4th, 2008 34 comments edit

The Debian world seems to be on a rant on why the RubyGem’s are bad and why we should all be using aptget instead.

For rants see: Wouter – Rails? Stay the f* away from my system, Gunnar Wolf – Ruby has a distribution problem as well as the official Debian take on RubyGems.

However, the Debian/Ruby Extras team fear that Rubygems will make it much more difficult to package and distribute Ruby software in Debian (similar concerns have been raised by other individuals and GNU/Linux distributions)

Updated: Just discovered that Gunnar actually wrote this really good post It’s just a different mindset. Not necessarily a sane one, though, which I think is a way better explanation of his concerns. I still don’t see why Gems is “the most obnoxious of them all”. Gem’s can and should improve. But at its current state I actually do like it.

I always wondered why their rubygem package was intentionally broken. But never took the time to worry too much about it, when it’s easy to uninstall it and install it from source.

RubyGems like CPAN are about being OS agnostic when writing and deploying our apps. At the application level, I really do not care nor want to care about what server os I’m running.

I develop on Mac and deploy to Ubuntu, Gentoo, Redhat and OpenBSD. Using aptget, rpm, portage and pkgadd is fine for initial server setup and on going maintenance, but for day to day deployment of applications nothing but a PITA.

Different worlds, different points of view

The fact is that we are talking about 2 completely different worlds here. The whole thing is something very much akin to the old Men are are from Mars, Women are from Venus meme from a few years back.

For me my focus is the application. Most Ruby developers write applications for a living. For sysadmins their focus is on keeping servers running. Most Debian maintainers probably come from that world. Regardless if my assumption is right or wrong on that, their focus is definitely on Debian and not on Ruby.

So you now have the situation where an American is laughing at the stupid Limies calling a cigarette a “fag” and an Brit laughing at the stupid yanks calling a bum a fanny.

Get over it. We come from different worlds and have to live together. If your job is maintaining a bunch of sysadmin type services such as mail, dns etc you know what you need to do your job. Application developers also know what we need to do our job. It might even be that these things are different.

However if your job as a sysadmin is to support several web applications server, then I’m afraid when it comes to the applications you are no longer king. You need to support the developers and not hinder them.

But as Gunnar says:

By using Ruby Gems, you dramatically increase entropy and harm your systems’ security.

This is what we politely call FUD in the tech industry.

On the server it is the sysadmin’s job to understand the benefits of postfix vs. sendmail. tinydns vs bind etc. It’s the DBA’s job to decide on when MySQL 5.1 feels stable enough to use in production.

It is our job as application developers to understand the finer points between RedCloth 3 and 4.1. RubyGems allows us to test our applications with specific dependencies and make sure that this is exactly how they are deployed.

This enables us to have the confidence to deploy without having to do full regression testing when moving from a Gentoo to a Ubuntu server. Or to deploy minor updates from our Mac’s onto a server.

After having spent years of managing servers manually, the simplicity and beauty of deploying with capistrano is amazing. Besides initial server setup (which I can soon wave goodbye to thanks to PoolParty) I want to focus on the application.

RubyGem’s give me the freedom to develop on a Mac/PC and deploy onto just about anything. I deploy onto Ubuntu, OpenBSD, Redhat and Gentoo.

aptget is fantastic at what it does, installing base software on my server. Maintaining my application dependencies is just not its job. The Debian community is right to be conservative. However the ruby world works at tremendous speed, change is part of our core DNA.

I don’t want to necessarily be installing a new MySQL or GCC version on a daily basis, but I am willing to use the often daily updates of ruby gems. As I have the tests that prove they work and fantastic transparency about what was changed via GitHub

The Debian maintainers should stop breaking software out of some misguided principal. For gods sake Debian is an Open Source OS not North Korea. You broke your RubyGem package, now fix it.

There must be some way of creating virtual packages that just install the gem. This method could be reusable for Perl’s CPAN packages and any other application level packaging system.

Update: Violent platform wars going on over this post on Hacker News

Posted December 4th, 2008 under:
Comments
rahuldave@gmail.com
Rahul Dave December 4th, 2008 destroy

It dosent have to be either or. Package metadata, either as rdf or something else, with a property defined namespace for ruby/python/etc packages is the way to go. The distributions should take the cue from gems/eggs etc as to the naming.

This problem was solved in 1998 with rpmfind.net which published rdf metadata for packages. But it was too early for other packaging systems to uptake. And we even have DOAP today..

wschenk@gmail.com
Will December 4th, 2008 destroy

> Brit laughing at the stupid yanks calling a bum a fanny.

What does that even mean? Neither of those words are American. I would rephrase is like “laughing at the stupid yanks for calls trousers pants.”

Also, “yankee” is a vaguely pegoritive term used by southerners to refer to people from the north east (the people responsible for the "war of northern aggression a/k/a the Civil War). Which I doubt is what people outside mean when they say Yanks…

pelle@stakeventures.com
Pelle Braendgaard December 4th, 2008 destroy

@Rahul I’m sure a ruby based meta package system could be created. But then again why not just base it on Gem?

I don’t know enough about the deb format, but on Portage and RPM it should be theoretically easy to create packages that proxy onto ruby gems.

@Will Just using British language there. Fanny as in Fanny Pack is American cutesy slang for rear end. In British slang it means the female reproductive organ. British people love laughing at the silly yanks with their fanny packs.

Trousers vs Pants is of course another great example. There are tons. I lived in both the UK and the US and have been inflicted by all of them. Of course each side is always sure their term is the correct one. Which of course it is for them.

In the UK you often here the term Yank used about Americans. Most often used in a kind of semi snarky sarcastic derogatory way.

postmodern.mod3@gmail.com
postmodern December 4th, 2008 destroy

I hear a lot of the comments that apt-get should control everything, but there’s some problems with Debian’s packaging hegemony.

Debian’s package maintainers are slow, very slow. It’s not uncommon for there to be multiple releases of a RubyGem in one month. I can’t afford to wait on another layer of testing and packaging, when I can run `rake test` or `rake spec` then `rake gem` myself.

apt-get only works on Debian, which is great if you work in a Debian-centric environment, but I prefer the flexibility of supporting any OS my users enjoy.

What would be nice, would be to have a system that automatically repackages .gem files as .dpkg files, in order to provide our own Debian package repository.

rgh@roughage.com.au
rgh December 4th, 2008 destroy

Whilst I agree with the sentiment that it’s good to have a platform independent package tool rubygems is so egregiously broken as to an embarrassment to the ruby community.

tim@example.com
Tim December 4th, 2008 destroy

The big point you omitted is that Rubygems are incompatible with the Filesystem Standard, which Debian aims to follow. There’s a huge number of tools, documents, and people who understand the FHS.

When a language’s adoption depends on people willing to muck up their filesystem in spite of their OS, they do have a problem. I’ve served Rails sites from Debian, and it’s not fun. (I’m not using Rails any more, and this is part of the reason. If you don’t play nice with the rest of my system, you’re not worth my time.)

Love them or hate them, Debian’s not going anywhere. These are the people who keep “non-free” separate from “main”, and renamed Firefox to Iceweasel. They’re not going to compromise to make life a little easier for Ruby.

Following open standards is the kind of “misguided principal” (sic) I wish more people did. Maybe the “ruby world” could use their “tremendous speed” to fix rubygems someday?

pelle@stakeventures.com
Pelle Braendgaard December 4th, 2008 destroy

@tim So let me understand. The thing that is so horribly broken in RubyGem’s is that it doesn’t follow FHS?

Isn’t that a tiny enough change that it would be easy enough to add to RubyGem without dumping the whole network of gems that are out there?

hongli@phusion.nl
Hongli Lai December 4th, 2008 destroy

Completely agreed. Part of the problem is that the Debian/apt supporters don’t even try to understand that there are people out there who have a different point of view than that of a hardcore system administrator’s. Debian supporters are also notorious for hating any foreign packaging systems for no rational reason other than that it’s foreign. The FUD that they’re spreading about RubyGems is all very familiar – after all, they used it on Autopackage as well! Autopackage is a packaging system that intends to work on multiple Linux distributions.

Let’s take a look at the things that Debian people say:
- “you dramatically increase entropy and harm your systems’ security.”
- “rubygems is so egregiously broken as to an embarrassment to the ruby community.”

In other words, “RubyGems sucks, I won’t tell you why but if you use it then you’re an idiot”.

If we look past the FUD, what are – according to them – the real reasons for hating RubyGems?
- “gem update —system” doesn’t work. A valid complaint, and it’s indeed stupid that it is (was?) broken. But is this a valid reason for ditching RubyGems and go all-apt instead? I don’t think so, tons of Ruby libraries aren’t even available via apt. If I install those libraries from source then the situation becomes even worse – I’ll end up with libraries that aren’t managed by any package manager! Strangely, Debian supporters have never expressed hostility towards source installations.
- Obtrusiveness of the requires_gem method. This argument has been invalid for more than a year now. requires_gem has been deprecated for as long as I can remember, and removed from RubyGems 1.3. RubyGems now hooks into the normal ‘require’ method.
- Not FHS compliant. Is this a valid complaint? I personally don’t care about the FHS. The files are managed for me by the package manager, and it all works, so why should I care where the files are.
What are the reasons for insisting on FHS compliance, other than “your car is red, I don’t like red so you suck”?

spampod@gmail.com
Ev December 4th, 2008 destroy

…yet another provocative post from yet another Rails contractor trying to build an “impressive” online profile.

But I’ll bite.

You’re focusing on Rails and web scripts too much. Debian isn’t a “commoditized” layer served to host glamorous Rails scripts written by geniuses who “move at tremendous speed”. Debian is a general purpose operating system, and Ruby is a general purpose language, and RubyGems is a general purpose packaging system. Nothing here was created specifically for Rails. In fact, this entire stack was designed to run many applications at the same time, written in different languages.

In order for such complex system to function properly, it needs to be free of misbehaving “pigs” that are pulling the blanked to one side. And RubyGems appears to bit one of such misbehaving applications.

I hope it will be fixed. It’s open source, things usually get fixed. Not a big deal. Meanwhile, production systems that are not 100% Rails-centric should avoid using RubyGems and stick to debian packages. They aren’t that old. The speed isn’t really that “tremendous”.

hongli@phusion.nl
Hongli Lai December 4th, 2008 destroy

@Ev: “In order for such complex system to function properly, it needs to be free of misbehaving “pigs” that are pulling the blanked to one side. And RubyGems appears to bit one of such misbehaving applications.”

This is yet another example of how Debian people spreads “$FOO is stupid, I won’t tell you why but it just is because I say so”-kind of FUD.

derek@derekperez.com
Derek P. December 4th, 2008 destroy

This is exactly why I won’t be using Debian in production anymore. Who are they to change the code to a product they don’t really understand.

pelle@stakeventures.com
Pelle Braendgaard December 4th, 2008 destroy

@ev lets hope my controversy really improves my job prospects. But seriously…

Debian is of course a lot more than that a commodity system, but for most Ruby developers it is a commodity system. It is a choice we make from a drop down list when picking a server image for our application.

@hongli Great comment. apparently I offended people calling it FUD, but without an explanation what else it.

@derek I am tempted. I wish I could get OpenBDS on slicehost or EC2. I generally like the choices the Debian crowd have made. It is the most BSD like of the major distributions.

There is also debate on this over on Hacker News

This is part of a reply I wrote there.

What I am saying is that there is a difference between the requirements of an OS and of a Web application. Aptitude is stricly speeking an application, but it is also system software.

My work depends on the Debian and OpenBSD guys being conservative and creating solid defaults. I want them to be so, as I don’t want to deal with that.

I am fanatic about OpenBSD myself, which is way more conservative and opinionated than Debian. I have spent years working with servers, being forced to do low level work. My main dev machine was Gentoo for many years. I understand the issues.

Complex systems are based on layers. The Internet for example is based on layers. The lower the layer the more conservative it should be. The higher layers are more diverse and allow greater flexibility.

After all I didn’t choose Ubuntu to run several of my servers for the sake of running Ubuntu. I choose them because I need a stable server OS that I can deploy my applications on.

For someone who is a core Debian developer that might be different. Maybe he does choose Debian for the sake of running Debian.

All I want for them to do is not break what I and 90% of other Ruby developers are doing. Also this is not just Rails. Almost all Ruby developers depend on Gem.

FUD is when you say something is dangerous without giving further reasons. So far in this debate, I have seen lots of people say RubyGem is flawed, but so far the only argument I have seen is that it doesn’t follow FHS.

I can live without Debian unbreaking their RubyGem package. I am not scared to install from source. But I still don’t understand the reasoning behind it.

If they don’t want to support real RubyGems it would be better for Debian users to remove the package all together as opposed to the trojan horse version of ruby gems that it is.

wosmvp@gmail.com
Jinzhu December 5th, 2008 destroy

I can’t agree more.

Install rubygem from source. Install gems form rubygem.

So I can use the same command in different OS.

actually I have used ubuntu/gentoo/arch/redhat

hongli@phusion.nl
Hongli Lai December 5th, 2008 destroy

@Pelle: agreed. Actually, the Hackernews comments were surprisingly constructive, in contrast to the FUD comments that Debian supports have posted so far. The first Hackernews comment explains clearly why he doesn’t like RubyGems.

His reasons can be summarized as:
1. RubyGems is a separate package manager, and not installed by default. Instead of typing a single ‘apt-get foo bar baz’ command, he has to type in that, and commands for installing RubyGems itself, and commands for installing gems.
2. RubyGems is interactive, e.g. it asks the user to choose a platform.
3. With apt, he can host an apt repository mirror on the local network. With RubyGems all packages have to be fetched over the Internet.
4. Because of point 3 he doesn’t know which package versions are going to be installed. Having multiple machines with different package versions can break things.
5. He claims that Ubuntu/apt has better support for upgrading to newer security/bug fix releases. That is, it is possible to tell apt to automatically upgrade to a new release that only contains security fixes, but not upgrade to a new major release with new features that can potentially break things.
6. He just doesn’t like the fact of having a separate package manager: “But even if they were to fix EVERYTHING on the list, it would still be layering one packaging system atop another, which means that we need to have two ways to do everything.”

Are his reasons valid? Let’s see:
1. I think this is valid, but it’s not something RubyGems can do about. Basically he’s complaining that Debian doesn’t install RubyGems by default.
2. No longer valid. RubyGems doesn’t do this anymore since version 1.1 or 1.2, and the right platform is automatically selected. Installation is fully non-interactive now.
3. Not sure whether this is a valid complaint. Yeah it takes a few seconds to download the packages, but why should one care? Also, it is possible to host one’s own gem repository. But I’m not sure how good the tools are compared to apt’s.
4. Not valid. He says this mostly out of ignorance. When installing gems one can specify exactly which version should be installed, e.g. “gem install rails —version 1.2.6”
5. Valid from his point of view. Less so from a Ruby developer’s point of view. Ruby has a serious culture of testing, and all dependencies are tested as well. Most Ruby developers only upgrade dependencies after having thoroughly tested them, even if in the event of patchlevel updates. I don’t think the ability to silently install security updates will be very useful in the Ruby community, but I might be wrong.
6. This is not a valid reason for concluding that RubyGems sucks/is evil/is broken, but is a valid reason for disliking RubyGems. But this too is not something that RubyGems can do about.

pelle@stakeventures.com
Pelle Braendgaard December 5th, 2008 destroy

@Hongli, Great summary. I haven’t had problems with gems for ages, so I wasn’t quite sure of the validity anymore.

hongli@phusion.nl
Hongli Lai December 5th, 2008 destroy

Oh and one more point about his post that I forgot to mention: RubyGems can’t handle non-Ruby dependencies. This is a legit complaint, but it’s also extremely hard to do without being platform-dependent. And one of RubyGems’s strengths is the fact that it is cross-platform.

I personally don’t care too much about this point. It would be nice if RubyGems can resolve native dependencies for me, but most of the time, as a developer, I already know what native dependencies I need and so I end up installing them with apt by hand anyway.

rgh@roughage.com.au
rgh December 5th, 2008 destroy

Hongli

For starters please can you indicate to me where in the sentence “rubygems is so egregiously broken as to an embarrassment to the ruby community.” do you see the word idiot? It says ruby gems (to be more specific gem) are broken, nothing more.

Of the top of my head:

  • It will reinstall gems even if it’s already correctly installed
  • When you upgrade it won’t tell you what it’s upgrading and give you the option to perform the upgrade
  • When you uninstall a gem it won’t tell you what’s dependent on it. Yes I know there is an option to simply remove all dependent gems but you don’t know what they are until they have been uninstalled. Or you could che
    check the depencies before but this is very, very painful with multiple gems
  • Appalling error reporting, eg. host unknown errors when the host is pingable.
  • There’s no way to fix a gem at a particular release so update won’t update that system.
  • Searching for gems is a joke and very slow.

The list goes on.

And that’s only in the latest release before about 1.2 and operating over a slow link they utterly useless. On many occasions I’ve downloaded gems by hand and install them manually.

Debian developers fiercely defend their systems/processes because they work. Any sys admin can go to a debian machine and very quickly work out where things are and what’s going on. If you start spraying stuff everywhere it degenerates into a chaos. If you find that an arrogant view point I don’t care, my systems work and are reliable. And when they do go wrong I don’t have to scratch around wondering where such and such file is installed.

“Debian supporters are also notorious for hating any foreign packaging systems for no rational reason other than that it’s foreign”

Oh Hongli, the irony of following that statement with: “The FUD …”.

If anyone is going to complain about the various merits of different packaging systems please save us all som
e time and at least have a good knowledge about both systems. And the rational behind them.

paulv@canonical.org
paulv December 5th, 2008 destroy

Hi, I’m a (debian) sysadmin and a ruby user. Weird, I know. It is actually possible to be both. I get paid to be a sysadmin, and I use ruby to that end. I also write ruby for fun.

The real problem I have with rubygems is that it doesn’t use /usr/local by default. It is a long accepted practice in the sysadmin community for the package management system to own /usr and anything that you install that is outside of the package management system to go in /usr/local (or somewhere else — this is why we have /opt and other things). This way I can look in /usr/local and say “I need to come back and pay attention to this and fix it by hand” when we do system upgrades.

Can you force rubygems to behave? Yes. GEM_HOME=/usr/local/lib/site_ruby/gems does a reasonable job, though now you need to make sure any daemon has that set in its environment, which is kind of a pain. In my opinion, /usr/local/lib/site_ruby/gems is where rubygem should install gems by default.

Would it be nice if security updates were done the same way security updates for the rest of the system were done? Sure. Would it be good if there was some way for rubygems to handle non-ruby dependencies? Yes. Are either of those things mandatory? No. Frankly, this is just as big a problem with Perl (and Python), though anything you install from CPAN gets installed in /usr/local by default, and Perl knows to look there by default. dh-make-perl helps, as well.

The reason we all use debian instead of RedHat or something else is that apt-get and dpkg are so amazingly well designed that the problem of package management simply goes away on debian. This means I’ve got time and cycles (both brain and machine) that I can spend getting important things done.

Every so often this issue comes up, and both sides bitch at each other, not really understanding each others point of view (“those silly ruby programmers” or “debians principles are misguided”). Meanwhile, I successfully maintain a bunch of debian machines with rubygems installed on them, in various places.

I just wish it was a tiny bit easier.

spambox22@gmail.com
Ev December 5th, 2008 destroy

Actually I like how this discussion/controversy turned out, there have been some good points made.

However, you guys are still way too focused on programmers as Debian customers and server-side software in general. Please understand that Debian people think in much broader terms and have a lot more users than just Ruby programmers.

You have to realize that for an average user of a general purpose operating system installing from source is not even an option. There are plenty of Ubuntu or Fedora “grandmas” out there who, when shopping for software, will be looking for deb/rpm/whatever packages for their system. Because it always works.

Those users won’t ever want to hear the word “install from source”. And this is great – modern package managers is one of the major forces that are moving Linux forward.

In that regards your gems ARE NOT cross-platform. They only usable to a miniscule percentage of population – Ruby programmers who compile stuff from source.

I like how Debian people are bending us, selfish programmers, to do the right thing. Hey, Java never played nice with native OS, and look what happened – it never graduated from the dark corners of rack-mounted server world: an average Joe isn’t using a single Java program even now in 2008.

I hope Ruby won’t repeat Java mistakes and I writing Ruby software for general audience will be a reality some day. Ever wondered why there is still so much C/C++ software? Because of ease of distribution. It’s kinda silly that Skype or OpenOffice are easier to install on Ubuntu than RedCloth.

pelle@stakeventures.com
Pelle Braendgaard December 5th, 2008 destroy

@ev I am absolutely fine with having debian packages of the major Ruby packages. If that can improve Ruby Gems that is fine as well.

But the target audience of Ruby Gems are not end users, but Ruby programmers. The target audience of ~99.99999% of applications written in Ruby are web users not desktop users.

This may beginning to change with new toolkits like Shoes and all the new MacRuby stuff for the Mac. However I don’t see this as mainstream for a while.

Shoes etc would do well to integrate themselves with the official package management tools.

Again the whole reason I wrote this post wasn’t to say my way is better than your way, it is to say we all have different needs.

I love aptget for getting all my non ruby services up and running in no time. I always had an aversion for rpm and always ended up installing from source on Redhat flavored servers in the past.

Aptget is the first time, I’ve actually installed such things like postfix and mysql from a package and been really happy with it. It’s great for that — and of course as a way for non sophisticated Ubuntu desktop users to install software.

There are many reasons why you wouldn’t like Rails, we all have different tastes and ideas. But still recommending against Rails because of ruby gems is silly.

hongli@phusion.nl
Hongli Lai December 5th, 2008 destroy

@rgh: I wasn’t talking about you specifically. I’m talking about the general responses that Debian supporters post about RubyGems. “RubyGems is broken I won’t tell you why but if you use it you’re an idiot” is exactly the kind of tone that I read in most of those responses.

You think that I do not have a good understanding of apt or foreign managers. You think that my claim that Debian hates foreign package managers is a bogus one. I am in fact an Ubuntu user, and have been so for several years now, so I have a pretty good understanding of apt. I’ve also been a RedHat, Fedora and FreeBSD user for many years so I understand Yum and Ports as well.
In 2003 I joined the Autopackage project, which aims to create a cross-distribution packaging system, intended to solve installation problems for desktop Linux users. The problem that we were trying to solve is the scenario in which Joe Average Desktop User wants to install $RANDOM_APP, but cannot:
- his distribution doesn’t provide a package for it, or it provides a package that’s too old and he has a legit reason for needing the latest version.
- he doesn’t know how to install from source, nor should he.
- or, his distribution happens to provide a package, but Jane Average Desktop User uses a different distro that doesn’t provide the package.
So we figured that we can solve the problem once and for all by making a packaging framework that works on all (or at least on most) Linux distributions. The emphasis was on desktop and average user. We’ve been fiercely opposed, especially by Debian people. They spread FUD such as that “Autopackage will cripple the system”, no explanation given other than that it’s not .deb. They refused to acknowledge our focus on the desktop and insist on the server sysadmin’s point of view. Doesn’t that sound awfully familiar? Oh yes… the same things that I’m hearing about RubyGems now!

@Ev: You like apt. You have good reasons to like apt. But this still does not solve the core issues:

- Rails 2.2 isn’t available via apt!
- What about people who don’t use Debian?

The Debian packagers are too slow. .debs do not work on OS X, for example. So what choice do we have other than using RubyGems?

jon@blankpad.net
Jon Wood December 5th, 2008 destroy

Reading through the comments here, and Debian’s position on gems, it sounds like the solution to this problem would be to make it possible to build a dpkg from a gem’s gemspec, with the installation paths appropriately set to fit the Debian policy.

At work I’d love to be able to say to a sysadmin “install this package from our apt server”, and have it work, straight away. Instead I have to specify that Ruby is installed, and then a copy of gems installed from source, and then a gem installed.

drnicwilliams@gmail.com
Dr Nic December 5th, 2008 destroy

I met some Perl ppl recently and they said they had a nifty script that converted their CPAN modules into debian apt-get bundles. I said “ooh can you show me now?” They said “no I’m drinking beer”. And I forgot to find him again the next day.

If someone can point me to how they build the debian bundles I’ll have a hack at how to wrap gems into them. It would be fun to have gems automatically deployable via apt-get (or macports, though I guess fink will do the job afaik). I’m just not sure where to start.

stefano.cobianchi@gmail.com
ste December 5th, 2008 destroy

@rgh:

“When you uninstall a gem it won’t tell you what’s dependent on it.”

  1. gem uninstall fastthread

You have requested to uninstall the gem:
fastthread-1.0.1
passenger-2.0.5 depends on [fastthread (>= 1.0.1)]
If you remove this gems, one or more dependencies will not be met.
Continue with Uninstall? [Yn]

drnicwilliams@gmail.com
Dr Nic December 5th, 2008 destroy

I’ve found http://pkg-ruby-extras.alioth.debian.org which claims to be a manually maintained list of gems that are converted into deb packages. The website even includes a “how to help your gem become a deb package?” tutorial

matt@reprocessed.org
Matt Patterson December 7th, 2008 destroy

Hey, I’ve been wrestling with these issues for a while, and started to try and do something about it. Basically, I decided to produce a .deb package building infrastructure for Gems – it was
actually pretty straightforward, and .debs turned out to be much nicer to work with than .rpms. See http://github.com/fidothe/dpkg-tools. It’s definitely not anything other than Alpha, but I’ve used it to more-or-less successfully package and deploy a rails app onto a clean Ubuntu install with no manual steps.

Sorry for the terseness of this reply, but I’m currently laid out with a chest infection.

Andreas December 7th, 2008 destroy

@drnic dh-make-perl is what you’re looking for.

It would be pretty nice if there was something similar for gems.

Personally I have no trouble using rubygems to install gems on my development machines, but from a sysadmin standpoint I want to do as much as possible to reduce system complexity. That means only running one package manager.

That said, if I was ever going to deploy a Rails app to one of those machines without rubygems, I’d be freezing the gems anyway…

This problem isn’t unique for Ruby at all. Python has it (distutils actually does suck), Perl has it (dh-make-perl helps), Ruby has it and that’s just the big languages with their own packaging systems.

It’s pretty clear to me that the correct answer is to provide packages for each distribution. Preferably this should be done in some automated fashion (gemspec -> package). The rationale behind this is simple: users shouldn’t have to deal with more than one package manager. Whether it’s a non-developer user, developer, sysadmin or whatever, the idea that you need to know and use CPAN, distutils, rubygems and whatever package manager your distro uses is silly.

evgeny.zislis@gmail.com
Evgeny December 8th, 2008 destroy

What is even more broken is Rails 2.2 handling of gems, the famous “rake gems:freeze” is just plain stupid.

Why it’s stupid you ask?

Well, several reasons.

1. for it to work it actually needs the gem to be installed on the system in the first place.
2. the directory created includes the version number – like vengor/gems/haml-2.0.5
3. it does not use the existing gemspec, but creates a new .specification file that someone in Rails’s world invented … WTF?

it effectively makes it impossible to properly use in a version controller project, since bumping a version for a gem in Rails forces you to:

1. update the version on the system
2. delete the old vendor/gems/xxx-x.y.z from version control
3. add vendor/gems/xxx-k.j.l to version control.

and looking at the code that is responsible for all this mess …. it’s just horrible!

Regarding Ubuntu, …. , well I have been keeping my gems in my user local directory for development, and if it’s a project that requires gems – then those are frozen in the project itself. I really don’t see much of a point to have gems installed system-wide, even in a shared hosting environment. It’s just a bomb waiting to explode, someday you bump the system-wide gems to a newer versions and half the applications stop working.

You can see my gemrc file here http://github.com/kesor/dotfiles/tree/master/gemrc

gwolf@gwolf.org
Gunnar December 9th, 2008 destroy

Wow… Quite a bit of comments. And yes, given that the author wrote a (very well phrased and balanced) post, I feel obliged to reply. But given that he refered to me first, I’ll just skip the chatter for later – I’m tired this time of day ;-)
Pelle, I agree with you – This problem is because we are from two very different mindsets. I have already said so – http://www.gwolf.org/soft/debian+rails is a witness to that point.
But I do not think the divide is between sysadmins and developers. I am a developer that grew from the sysadmin stance, but that’s not AFAICT that much the fact in Debian.
Thing is, in a distribution, we try to cater for common users. I have a couple of Rails apps under development that I expect to be able to package for Debian, and I think can be very useful for the general public.
Now, how is the user experience when you install a desktop application, in whatever language/framework it is written? You don’t care what the platform is – you care that it integrates nicely with your environment. Yes, the webapp arena is a bit more difficult – but we have achieved quite a bit of advance in that way. Feel like using a PHP webapp? Just install it, and it’s there. A Python webapp? Same thing. A Perl webapp? As long as you don’t do some black magic (and that’s one of the main factors that motivated me away from mod_perl), the same: Just ask apt-get to install it and you are set.
But… What about installing a Rails application? From a package manager? For a user who does not really care about what design philosophy you followed, who might not even know what a MVC pattern is?
Thing is, distributions aim at users. And yes, I have gradually adopted a user’s point of view. I very seldom install anything not available as a .deb – and if I do, I try to keep it clean enough so I can package it for my personal use later on.
Anyway… I will post a copy of this message in my blog (http://gwolf.org/), partly as a reminder to come back here and read the rest of the buzz. And to go to the other post referenced here. And, of course, I invite other people involved in Ruby and Debian to continue sharing this – I am sure I am not the only person (or, in more fairness, that Debian’s pkg-ruby-extras team is not the only team) interested in bridging this huge divide and get to a point we can interact better – And I am sure that among the Rubyists many people will also value having their code usable by non-developers as well.

wouter@debian.org
Wouter Verhelst December 9th, 2008 destroy

You link to my rant, and in fairness, I didn’t try to be constructive on that post (I did on the follow-up which I posted at http://grep.be/blog/en/computer/cluebat/rails_followup earlier today).

I agree with the basic statement that Debian Developers and Ruby developers are of a different world. In fact, the main problem I have with RubyGems is that it ignores the other world.

To me, it’s perfectly fine if you want gems to be easily installable cross-platform. The point is, I don’t care whether you install software through RubyGems, .deb packages, RPM kludges, or by threatening your mother-in-law until she does it for you, so long as I can do it my way: by running ‘apt-get install great-ruby-based-webapp’.

Currently, because of some choices the RubyGems developers have made, and because of the choices the Debian Developers have made in the past, this simply is not possible. Now I’m not going to unilaterally declare who’s right and who’s wrong, but given the background and knowledge I have about how Debian works, you’d have to be quite convincing to bring home the point that Debian would have to be redesigned from scratch in order for RubyGems to work properly on Debian. I’ll leave the details to the pkg-ruby team — who’re actually working on ruby stuff, as opposed to me.

Regarding FHS: there are very good reasons why one could want the entire system to follow the FHS. The details of that are outside the scope of this discussion, but the bottom line is that, at the very least, it should be possible for your system to support that if you want to be able to run on Linux systems.

tutufan@gmail.com
Mike December 14th, 2008 destroy

If the Debian position on this seems unreasonable, I recommend you step back and meditate on it at great length. Those guys have been thinking about stuff like this for a long, long time, and arguably do it better than anyone else in the world. I think you ignore their instincts at your peril.

It’d be nice if we could just ignore OSes with broken/nonexistent package management scheme (cough Windows cough), but that’s not realistic. At the same time, we shouldn’t break or warp the well-designed schemes that exist just to pander to the least common denominator.

Caveat: I’m not a ruby programmer, although I might be someday, and I like ruby and want it to succeed. If ruby gets this wrong, though, it’d probably be a showstopper to me ever trying to use it.

peter@mailinator.com
Peter December 15th, 2008 destroy

As a user of both Ruby and Debian, I find the Debian position entirely correct. I have a bazillion things installed on my system. Most of these things I do not want to maintain. I want Debian to install security updates for me. I want them upgraded when I upgrade my server. This includes Ruby and most Ruby applications. Debian does a fantastic job of this. If Ruby applications used gems, I would lose access to Debian’s security infrastructure. I run several servers (Wiki, MP3, etc.) written in several languages. I did not write these, and I do not do anything fancy with them. They are personal servers. Debian maintains them for me, and I appreciate that.

When I want to write a web application, I install gems, Rails, and friends myself. I bypass Debian package management entirely, and I use gems. As you pointed out, this is easy to do. At that point, I know that I am on my own for security. I know that I am on my own for upgrading. This is a pretty minor overhead (~30 minutes initial, and ~30 minutes for each upgrade) when I’m developing an applications (~8 hours per week to ~40 hours per week).

This would be an obscene overhead if I had to do it for Ruby/Rails, Python/Django, Perl, and the dozen other similar packages on my system.

jim@jimpick.com
Jim Pick January 24th, 2009 destroy

I’m an old school Debian developer and I’ve done a lot of RPM packaging and development with many systems with their own package collections.

Fundamentally, if you have more than one packaging system, you’ll have some conflict.

I think that packaging systems could be done better. They are all still sub-optimal.

I’m currently attracted to the idea of factoring out all of the metadata from the packaging system, and dropping it into a global-scale Wikipedia style system (I’m using Freebase). Ideally, a capable, neutral schema will evolve via NPOV debates. Expose it semantically to the LOD community. Then pull it via a query, and substitute it into your packaging/build system of choice. I’m using NixOS.

crazypete62@yahoo.com
Peter Garner July 21st, 2011 destroy

Basically what i am getting from all this is that everyone is raising really important reasons why Ruby Gems is simply crap. (Lack of security, lack of versioning, etc.)

>But as Gunnar says:

>> By using Ruby Gems, you dramatically increase >>entropy and harm your systems’ security.

>This is what we politely call FUD in the tech
>industry.

No that is what we rather alarmingly call a massive understatement in the tech industry. Only a Rube would call it FUD. It is too bad, Ruby was a very promising language and Gems has utterly destroyed any utility it might have. I BELIEVE you Rubes when you say you can’t understand the importance of security, file checksums, versioning, point source distributions for common packages, etc. I just don’t want code written by someone who can’t understand these things running on my system. (No i don’t use twitter either.) I guess the real question is why the hell are the admins and managers of these distros even CONSIDERING packaging software written by someone whose technical knowledge is so low that s/he doesn’t even know enough to avoid Gems?

Best Wishes,

Peter