DebGem is on its way
This morning, I got a mail that made me very happy. I followed it up a bit, and some hours later, echoed it over the pkg-ruby-extras list. And, yes, a blog posting won’t hurt :) I have done some rantings on why it is so painful to integrate cultures such as Debian and Rails. Those rants were part of quite a large rant-net and attracted a fair share of traffic/comments over here. Flamefesting over your blog is fun! :-) but anyway, I am delighted to say that at least some people worth their weight in code were watching, interested. The mail I got this morning (yes, follow the links above!) was from Hongli Lai, one of the very nice people at Phusion - The people behind Phusion Passenger (a.k.a. mod_rails) and Ruby Enterprise Edition. Yes, people with a very different mindset to mine (specially when it comes to being a 100% Free Software person). Hongli invited me to try their new DebGem service (still in Beta, although quite usable as it is). They are offering an auto-built full repository of Rubyforge, translated to Debian packages. They are currently supporting Debian 4.0 (Etch) and Ubuntu 8.04 and 8.10 (Intrepid and Hardy). And, yes, installing any arbitrary Ruby module is now just as easy as aptitude install libsomething-ruby. For over 20,000 Gems. There is a catch, yes. The service is currently free, while they finish the public beta period. Their pricing is available. Best luck to you guys. And… Shall you enjoy fierce competition from Debian proper! ;-) [Update]: They just posted the official Beta announcement for DebGem
Comments
dcu 2009-10-17 16:10:00
free/open source application to convert ruby gems to deb package
today I released an app to convert ruby gems to deb, it’s still alpha though (I wrote it this morning ;).
you can find it here: http://github.com/dcu/deb2gem
Eric 2009-01-06 08:35:51
I understand your concerns
I understand your concerns but I hope you are not asking “please do not share free software that we distribute”
gwolf 2009-01-05 20:18:51
Of course you can rip it now…
But the service will include updated packages in the future. And probably you will be able to somehow update them later on… I’d invite you not to do it. You and I don’t need 20,000 Ruby packages, it is quite simple to package a simple Ruby package for Debian. I think this service is for and will be used mostly by administrators which host Rails applications and don’t want to get involved further in packaging. We can actually do the packaging - and a human-made package will quite probably be of a higher quality.
gwolf 2009-01-07 15:51:00
Y’know…they could
Most of the Ruby modules are under an MIT-style licensing, so they could redistribute them in a completely closed, propietary way if they so wished. And also, look at /usr/share/doc/*/copyright - The copyright for the upstream code itself is often different from the packaging done for Debian. They can set up a complete Apt repository without making their packaging free. And, of course, you have models such as OpenBSD’s, where the code itself is completely free, but the ISO images are copyrighted and non-redistributable (and meant to be the project’s main income). Yes, what they do feels awkward to us Free Software people. But I do feel it can be useful for many users.
gwolf 2009-10-17 21:22:28
Typoed URL!
Hi,
You managed to post the wrong URL! ;-) Fortunately, it was an easy guess: http://github.com/dcu/gem2deb
Looks interesting! I am too tired right now… But I do want to check it soon, and probably upload it into Debian as well. Thnks!
Hongli Lai 2009-01-06 06:19:50
Hi Jeff. We won’t stop you
Hi Jeff.
We won’t stop you from mirroring the beta apt repository, but please keep in mind that we spent many, many weeks developing this service. Keeping 20000 packages up to date is hard work, which is why we are charging money for it. I hope that you can understand that we’re just trying to make a living here while giving people a service that they need.
Hongli Lai 2009-01-07 03:44:51
Of course not, you are free
Of course not, you are free to redistribute the software since it’s all open source. If you understand that we’re charging for our skills, time and services, then that’s ok. :)
Hongli Lai 2009-01-07 03:59:13
Our conversion process is
Our conversion process is automated. However, writing such automation tools is far from trivial, and we’ve already invested a lot of time into developing such tools. Furthermore, the conversion process is not 100% automated: a lot of gems need to be manually fine-tuned, which can take a lot of time and effort.
The Ruby-on-Debian packaging problem has existed for years. I very much appreciate the great work that the Debian Ruby packaging team is doing, but their man power is limited, and it seems that the Ruby world is moving faster than they are able to keep up with. There are Ruby packages which are outdated or require maintenance. Our DebGem service intends to solve these problems by providing high-quality and up-to-date packages for a large number of different distributions and platforms. Even with automation tools, this is a huge undertaking and requires constant maintenance.
So in essence, people pay us to do the hard packaging work for them so that they don’t have to bother with this themselves, or to wait on volunteers who might not always have time.
I hope this post answers your question. If not, please feel free to ask more. :)
Hongli Lai 2009-01-07 10:45:48
I was told that I might have
I was told that I might have misunderstood your question, so perhaps this answer would be more appropriate to you:
A service such as DebGem didn’t exist before. We are the first one to try to offer Debian packages for all 25000 RubyForge and Github gems. We’ve worked hard on this solution and we want to be able to make a living off this.
Jeff Schroeder 2009-01-05 17:57:11
Easy way to get around the pay restrictions
sudo apt-get install apt-mirror :)
I’m mirroring this right now and could be convinced to upload it somewhere if you’ve got the bandwidth for a repository.
Kevin Mark 2009-01-06 16:47:56
what are they providing? Is it proprietary?
are they: (a) taking a ruby gem and turning it into an equivalent debian ruby package, (b) making a debian repository out of it, (c) hosting it and then want folks to pay for the (d) server and (e) development costs?
On point b, debian and its mirrors can make repos. On point c, debian and its mirrors host debs. On point d, debian and its mirrors pay for their own hosting.
On point e, free software is developed in both a volunteer and non-volunteer setting, so you usually make the code available and lets both folks collaborate on it, thus reducing the overall costs to the businesses.
On point a, are you saying that you produced a proprietary method to convert from gem to deb and dont want to release that work because you want to make income from this service?
I supposed if the gem to deb conversion is not automated, and requires an effort to code each deb by paid folks, then I guess I see why you want to charge for it.
But I would be surprised if there could not be a method to automate some significant portion of the gem to deb conversion. If that method exists, I’d would have thought that would be something worthwhile to work on. If some industrious hacker can examine the gem and your deb, I’d expect them to be able to reveng what your process is and duplicate it, no? Thus, why keep it non-public? I hope these question make sense as I have not seen the details.
lanjoe9 2009-01-06 03:41:17
A note
As a curious but non-useful note, Hongli Lai is the same person who created the package manager system for DevC++ (a free IDE for windows that both went defunct and gained some popularity in my faculty at the same time).
scientes 2009-01-12 23:36:09
why cant it be possible to
why cant it be possible to create basically apt-drivers? and have it just pull directly from gem, with only a metadata/list perhaps being kept centrally? why does apt have to be inflexible? couldn’t a fake apt-proxy simply package as a deb after downloading and building rdocs?
I think having packages come directly from the maintainers is generally a good thing, and the more automatic the better, howveer there are of course a few issues to be thought about if it would become completely automatic. Namspace issues, but genearlly that would be easy, just prefix everything gem- or something similar. I think apt is robust but there is no reason it has to stay closed as to it different steps, ruby apps are differnt than most as they are the source, they dont need clean compiling, and they already have system to deal with having multiple versions at once etc.