Seen on The Ruby Reflector (a blog aggregator for the Ruby community):
Under no circumstance should you install Ruby, Rubygems or any Ruby-related packages from apt-get. This system is out-dated and leads to major headaches. Avoid it for Ruby-related packages. We do Ruby, we know what’s best. Trust us.
(source)
It’s always nice to see people appreciate your work. :-)
Well, it’s kind of deserved, isn’t it? The language-specific packages will always be more up-to-date than the distribution-provided ones, and as a web developer I guess it’s best if the least amount of deployment code cares whether it’s running over an APT, RPM, or ports-based distro.
IMHO distribution package systems should integrate with CPAN/gems/tlmgr rather than duplicate the work. Ideally that would mean transparent interoperability, but of course that might be a little difficult :) A practical compromise would be if the distribution could watch over the language packages, pass configuration options, and maybe ensure they do not step outside the distro idioms…
The same article tells you to install git-core and build-essential using apt. Not sure why it’s acceptable to use an antiquated system to install those and not anything ruby, but as stated, the author knows best, so just trust him.
Lucas, keep up the good work :) Your efforts are very much appreciated by those who understand the situation.
The Ruby community’s understanding of how libraries are supposed to work should not be thought of in terms of how bad it is in comparison to sanely managed languages, but, rather, how much better it is in comparison to Smalltalk.
Or, at least, that’s what I tell myself every time I trip over a standard library API change in a minor release.
I always had a hard time understanding why Ruby complained about this so much, but I think I finally figured it out. Ruby developers complain about old versions in distributions and suggest using upstream directly, the same way many other upstreams would complain if distributions ship old versions. The difference: in the Ruby world, “old” means “from yesterday, and thus at least two API breaks ago, and unsupported because we don’t bother with backward compatibility”.
For analogous situations, look at ffmpeg before they started having stable releases and APIs, or mplayer before they cared about distro packaging, or pretty much any other upstream that doesn’t (or didn’t) care about stable versioning. (Credit to all the cases I mentioned for falling squarely in the past tense, now.)
@Damien:
> Well, it’s kind of deserved, isn’t it? The language-specific packages will
> always be more up-to-date than the distribution-provided ones, and as a web
> developer I guess it’s best if the least amount of deployment code cares
> whether it’s running over an APT, RPM, or ports-based distro.
Gosh, I didn’t realize that Ruby had become a web-only language. I really
should move to Python.
> IMHO distribution package systems should integrate with CPAN/gems/tlmgr
> rather than duplicate the work. Ideally that would mean transparent
> interoperability, but of course that might be a little difficult :) A
> practical compromise would be if the distribution could watch over the
> language packages, pass configuration options, and maybe ensure they do not
> step outside the distro idioms…
What’s the point? I mean, if apt-get just adds an indirection layer on top of
rubygems, what’s the added value for Debian users?
> Gosh, I didn’t realize that Ruby had become a web-only language.
Grow up, that was an example…
> if apt-get just adds an indirection layer on top of rubygems, what’s the added value for Debian users?
NB. Of course, my comment applies to any interaction between packaging systems, not just Debian and rubygems.
Simplicity. Up-to-date packages for software that does not evolve at the same rate as the distro. Developers having the ability to install devel gems from github or wherever without fearing to overwrite APT’s. Not wasting a team of maintainers on doing the packaging work a second time. And “an indirection layer” does not necessarily mean that it does nothing. I imagine it could detect dependancies to C extensions and install the corresponding .debs.
And what’s the value with the current approach?
> Simplicity. Up-to-date packages for software that does not evolve at the same rate as
> the distro.
Why does it have to involve APT? You can do it already by installing rubygems (either the debian package, or from source), install the gems you want manually, and gem update.
> Developers having the ability to install devel gems from github or wherever
> without fearing to overwrite APT’s.
That’s FUD.
> Not wasting a team of maintainers on doing the packaging work a second time.
> And “an indirection layer†does not necessarily mean that it does nothing. I imagine
> it could detect dependancies to C extensions and install the corresponding .debs.
Rubygems could do that. You trust it not to break your system when you gem install something, so you could trust it to run apt-get install libmysqlclient-dev for you, for example. Or to download the mysql sources and build it from sources, so you don’t have to use the outdated version provided by Debian. Why should you trust Debian to provide a good mysql package if you don’t trust it to provide good Ruby packages, after all?
Anyway, I don’t see why wrappers managed by a Debian team are required for that.
> And what’s the value with the current approach?
Some people in the Ruby community are happy with building everything from source. I understand that. What those people don’t understand is that some other people just want to run applications written in Ruby, and don’t want to care about Ruby having its own packaging format. At some point, you need to draw the line somewhere. Packaging Ruby libraries in Debian is useless? OK. Packaging the Ruby interpreter is useless because there’s RVM? OK. But what’s useful in Debian, in your eyes? If you run GNOME, you can build it using jhbuild, which is quite easy to use. So are the GNOME packages useless too?
> Why does it have to involve APT? You can do it already by installing rubygems (either the debian package, or from source), install the gems you want manually, and gem update.
My point. That’s probably what most devs do, so besides Ruby itself, apt packages are redundant for them.
> That’s FUD.
Yes, I’m uncertain about what happens. If I install a gem, surely it takes precedence over the library from apt? What if I then intall a Ruby app via APT? how does APT translate the version dependancies in rubygem’s require statements?
> Rubygems could do that. You trust it not to break your system when you gem install something, so you could trust it to run apt-get install libmysqlclient-dev for you, for example.
But distro maintainers know how to invoke rubygems to install dependancies, whereas rubygem writers do not know what distro their users use (and it would be absurd to code support for each and every distro packaging system inside rubygem).
> At some point, you need to draw the line somewhere.
Indeed. The source troll/comment is clearly destinated to developers, though. Independant from the fire-and-forget apt-get installation of some end-user application, then.
In the end I just wish there was some generally accepted conventions that distro and language packaging systems to coexist cleanly, and ideally to interact one with another.
> > That’s FUD.
> Yes, I’m uncertain about what happens. If I install a gem, surely it takes
> precedence over the library from apt? What if I then intall a Ruby app via
> APT? how does APT translate the version dependancies in rubygem’s require
> statements?
If you installed a gem, it always takes precedence if the application does “require ‘rubygems'” before requiring the libs. If it doesn’t, your gem will be ignored with 1.8, and taken into account with 1.9.1, but that’s the way it’s supposed to work.
> But distro maintainers know how to invoke rubygems to install dependancies,
> whereas rubygem writers do not know what distro their users use (and it
> would be absurd to code support for each and every distro packaging system
> inside rubygem).
Why would it be absurd? If you develop your own packaging tool, at some point you need to take the specificities of your target platforms into account. Or at least not ask the target platform to solve your problem for you.
> In the end I just wish there was some generally accepted conventions that
> distro and language packaging systems to coexist cleanly, and ideally to
> interact one with another.
s/language packaging systems/rubygems/. Ruby is the only language with which there’s so many problems.
> Or at least not ask the target platform to solve your problem for you.
Which is what they are doing by bypassing apt entirely :)
> Ruby is the only language with which there’s so many problems.
Oh well, then they surely are wrong.
@Damien – imagine the users of Debian and Ubuntu, trying to install a web app like redmine or the like. Should they go down the road with gems for everything, including compiling gems with C-bindings, just because they want to have a web app up and running? That’s just ridiculous. They’re not all Ruby developers.
For the record: I develop using Debian’s ruby and rubygems, and use upstream gems for most other things – works perfectly. Never liked rvm.
I hope Ruby community will mature with time. Maybe this even will happen like in 10 years or so.
Maybe I should start learning a bit of Lua in case Ruby completely crumbles to “compile it yourself, dude, every bit of it” line…
> > Or at least not ask the target platform to solve your problem for you.
>
> Which is what they are doing by bypassing apt entirely :)
No, they are not. What they do is that they have strong requirements on the system (gcc, git must be installed for RVM, usually using APT), and at the same time hold a position where they say “you should never ever use APT, it’s evil”.
I perfectly understand that RVM and rubygems are the right solutions for some users. What I can’t handle anymore is all the people that try to explain that this is the right solution for everybody.
Thanks for posting this Lucas. Your work with Ruby on Debian / Ubuntu is super appreciated. I am very passionate about Ruby, but I am quite certain that Debian and Software in the Public Interest (and yes Ubuntu, too) is correct in its position on the file system hierarchy. I hope that the Ruby community will come to the same conclusion that I and many before me have reached: that Debian is the way it is for very good reasons and the benefits far outweigh the drawbacks.
Happy New Year! May Ruby 1.9.x and Wheezy have a prosperous and cooperative 2011!
@nona I’m not arguing against binary packages, but against having two overlapping packaging systems. Now I don’t know how it’s done exactly in Debian, but I guess a Ruby library installed via apt is not visible in rubygems’ catalog. So if you need to install something via gem that requires that lib, you end up with two copies of it. Now I know gem’s handling of multiple install prefixes is less than perfect, and I don’t know how they make it work in other languages, but you see the point. Ideally, Debian would provide debianized works-out-of-the-box packages for apps like redmine, while installing libs so they seamlessly integrate with other gem-installed stuff
Also I guess the main complaint from developers/fans of bleeding edge is that maintaining the .deb requires manual work, so the .debs lag behind the gems. If there was a build server that generated .debs automatically each time a new version of a gem is released, I bet there would be much less complaints.
@lucas “you should never ever use APT, it’s evilâ€. yeah that’s nonsense for most users I agree
I am glad to have Debian packaged RubyOnRails. I prefere it to download and compile everything myself.
I have tried develop RubyOnRails-applications on both MS Windows and Debian, and I’ll take Debian packed software and day of the week.
Thanks for the work.
(A user)
> I perfectly understand that RVM and rubygems are the right solutions for some users. What I can’t handle anymore is all the people that try to explain that this is the right solution for everybody.
It’s clearly a blog targeted at Ruby developers. You have to take context into account rather than just pulling snippets like that.
You must take part in a contest for among the finest blogs on the web. I will recommend this site!
Merry Christmas and Happy New Year everyone. I wish 2011 will be successful for everybody.