
Giving up on Ruby packaging - philf
http://www.lucas-nussbaum.net/blog/?p=617
======
tptacek
Can I be the jerk on this thread to raise my hand and say, "from what I can
see, every single thing Debian has done with Ruby, from the way they split
Ruby up into separate packages to the mindboggling damage they inflicted on
RubyGems, has worked to the detriment of Ruby and provided no discernable
benefit to end-users"?

For at least a year now, I've simply accepted that Debian's Ruby lives in a
parallel bizarro-universe, rm'd any trace of it that intrudes on my own (real)
universe, and installed everything from source.

I write this not to feel better about myself but to attract the passionate,
angry disagreements that will help me better understand the problems this guy
was trying to solve, so I can understand how he looks at the world and what
his decision means instead of silently hoping that this post means nobody is
going to try to integrate Debian and Ruby anymore.

~~~
bryanlarsen
You've done the right thing, but attributed blame in the wrong place, it's
Ruby that's in the parallel bizarro-universe.

Ruby, RVM, ruby-gems etc were all designed and built for developers. APT was
designed and built for system administrators.

In the world of system administrators, API differences between versions 2.3.5
and 2.3.8 would be considered bugs. In the world of Ruby/Rails, that's just
standard practice. APT would not let you install both 2.3.5 and 2.3.8
simultaneously because that would be silly. It is silly, but it's useful for
developers. The detriments are obvious to everybody but the Ruby community --
DLL hell is one of the major factors in the decline of the Windows platform.

So yes, keep Ruby off in it's own parallel universe, partitioned off using RVM
or bundler. As a developer, this brings you many real benefits. But recognize
the real detriments to normal users and system administrators, and place the
blame squarely where it belongs -- on the Ruby community.

~~~
tptacek
Ruby is overwhelmingly used by developers. I understand that there are a few
projects that are so popular and useful that end-users and admins might want
to install them without actively developing for them. But the decision to
optimize Ruby for that use case, instead of for its overwhelmingly more common
use case as "developer tool", just - seems - wrong.

I don't "blame" anyone. I think Debian is wrong about Ruby.

~~~
bryanlarsen
But is that a coincidence? Python is widely used by end users -- a large
portion of the Ubuntu apps are written in Python. Ruby is widely used by end
users via the web (zillions of twitter users, for example), but it is not
widely used for desktop apps, even though it would be a good language for
them.

~~~
tptacek
It wasn't Debian's place to decide that maybe Ruby should work more like
Python. Packaging, by the way, is a longstanding sore point with Python
developers; RubyGems is one of the few clear wins Ruby had over Python.

~~~
thristian
Really? I haven't used RubyGems, but one of my favourite things about Python
packaging is that I can take a proper Python distutils-based package, and in
about thirty seconds create a usable RedHat package that my sysadmin
colleagues can safely and easily deploy to our production systems, alongside
all the other updates they manage.

I believe various Debian packaging "helper" scripts (like Joey Hess'
"debhelper") have built-in support for Python distutils packages too.

------
Corrado
I really hate to see Lucas burn out and I think the Ruby & Debian communities
will both be negatively affected. I'm a Debian Ruby user whose contributed a
tiny bit (first Redmine package) and I have watched Lucas and the rest of the
team repeatedly bang their heads into a wall when trying to get agreement on
something from either side.

My personal view is that the Ruby/GEM packages should be laid out like the
Perl/CPAN, which seems to be doing just fine.

If you want to help, go to the Debian Ruby Team page
(<http://wiki.debian.org/Teams/Ruby>) and join us
(<http://wiki.debian.org/Teams/Ruby/RubyExtras/JoiningTheTeam>).

~~~
runjake
I love Perl, and I'm a Perl god. But CPAN is a plague unto it. If any piece of
software should be called a ghetto, CPAN is it.

~~~
telemachos
I like cpanm[1] quite a lot. Have you tried it as an alternative installer for
modules? (I'm no Perl god, but I still maintain a healthy chunk of Perl code I
wrote for sysadmin things a few years ago. I find that cpanm does exactly what
I need it to, without the overhead of CPAN.)

[1] <https://github.com/miyagawa/cpanminus>

------
Vivtek
How many other free software projects are significantly hindered by the
language used by the main developers? I found that the most fascinating aspect
of this post. Software tends to be so very English-centric that the fact that
Ruby is Japanese really stands out.

~~~
kscaldef
I believe that early on most of the OCaml community was French-speaking.

Personally, I found that aspect of the article borderline offensive. Oh,
people shouldn't speak their native language because... speak English dammit!
Oh, and don't release software on Dec 25th. (News flash: the majority of the
world population does not celebrate Christmas.)

~~~
moe
_Oh, people shouldn't speak their native language because... speak English
dammit!_

Nothing offensive about that, as long as it's expressed in a polite manner. To
me it sounds like a constructive proposal from someone who has witnessed the
problems first-hand, he's not just "ranting from the sidelines".

This is not about imperialism. It's about improving the communications in a
project that has long turned international. English _is_ the lowest common
denominator. Refusing to acknowledge that simple fact does not help anything.

~~~
jamtur01
Also given Lucas' native language isn't English either it's hard to claim
imperialism.

------
davidw
I started using RVM a little while ago, and... I am not that excited about it
(although it is well done and mostly works as advertised). It seems like the
direction Ruby is going is to have things like Rails applications that require
their own version of Ruby and a whole slew of gems, which also means that if
you have a number of applications, you start getting a large amount of
duplication? I'm not entirely sure as I'm new to the system, but it adds an
extra level of installed stuff that I'm not 100% comfortable with.

Edit: as an aside, Zed Shaw's wild attacks and untruthful accusations against
Debian were some ugliness that the world could have done without. I hope Lucas
finds other places to more productively (and happily) employ his talents in
the free software world.

~~~
gregwebs
You don't have to have any duplication (with RVM and bundler) if you use the
same ruby version on your projects.

Requiring an exact version of Ruby for a project is a practice that avoids
rare issues of version inconsistency.

~~~
davidw
> Requiring an exact version of Ruby for a project is a practice that avoids
> rare issues of version inconsistency.

If they're rare, you ought to identify them, and, rather than require an exact
version, say "this version or greater", and spell out exactly why in the
comments, so that future users of your code will know precisely what code is
affected and be able to reason about it themselves.

~~~
mechanical_fish
_say "this version or greater"_

That only works if all future versions are guaranteed to be backwards-
compatible with the current version. A guarantee that does not exist.

See here:

[http://yehudakatz.com/2010/08/21/using-considered-harmful-
or...](http://yehudakatz.com/2010/08/21/using-considered-harmful-or-whats-
wrong-with/)

A version requirement is a statement that "I have tested this code with these
versions of the dependencies and verified that it works." Yes, given
sufficient time and energy one can also test the code against many older
versions of the dependencies, find any bugs, and include explanatory comments,
as you suggest. But one can't test against the dependencies _as they will
exist in the future_.

~~~
davidw
> That only works if all future versions are guaranteed to be backwards-
> compatible with the current version. A guarantee that does not exist.

It's not the sort of thing that's easy to prove empirically one way or the
other, but I get the feeling (despite being a heavy user and fan of Ruby) that
other languages take that guarantee more seriously. It's a tradeoff: by not
spending much effort on backwards compatibility, they can spend more time
developing "cool new stuff". Users get more new stuff faster, at the expense
of having to worry more about upgrades breaking things.

~~~
mechanical_fish
_other languages take that guarantee more seriously_

It's more than just a feeling. They certainly do.

But: Those languages are there. They live! Perl 5, for example, is there. It
has not gone anywhere. Its community would _love_ for you to use it. The fact
that some people sometimes decide to use other things tells us something about
the value of backwards compatibility in uncertain times.

My impression is that Ruby does change uncomfortably quickly, but not so
quickly as its problem domains are changing. The rate of change of our
software ecosystems is a symptom, not a cause. My god, the things that have
happened in the last decade. Cheap virtual machines in the cloud. Widespread
use of distributed version control. Client-side web apps. Mobile applications.
NeXT cubes in your pocket for $250.

~~~
davidw
> The fact that some people sometimes decide to use other things tells us
> something about the value of backwards compatibility in uncertain times.

Java, which seems to take it fairly seriously, is way more popular than Ruby
is.

I agree that the world changes quickly, but disagree that you need to
radically change stuff all the time.

For instance, in Rails, they went from <%= to <% back to <%= for forms. To me
as an end user, that is completely useless churn.

Like I've said, I like Ruby and am mostly happy with it, but there's a
tendency to rush off after the 'latest new thing!' that at times I view as
counterproductive.

~~~
FooBarWidget
You're kidding me, Java? We're talking about compatibility in the context of
avoiding code duplication. Java itself is very good at compatibility but
compatibility of third party libraries are wildly different, plus Java apps
tend to vendor all third party libraries regardless of compatibility
guarantees.

As for the Rails <%= thing, where did you get the idea from that they went
from <%= to <% and back to <%=? Did all of this happen within the same release
minor release cycle? Rails has a strong compatibility policy for minor
releases and only tend to break things between different minor releases.

~~~
davidw
I meant Java the language; I don't know much about the ecosystem.

The tag thing in Rails has happened over time, not in the same release cycle,
but still it's annoying.

~~~
FooBarWidget
Are you seriously complaining about a compatibility breakage that conforms to
their compatibility policy? You knew exactly what kind of guarantees you
signed up for. You can't expect developers to never break anything unless you
don't want any form of innovation. And as far as I know the old <% form_for %>
_still works_! You don't have to use <%=.

~~~
davidw
> Are you seriously complaining about a compatibility breakage that conforms
> to their compatibility policy?

Yes, I am. Just because they have a policy in place doesn't mean that I lose
my right to air my opinions.

The point with the <% thing is that it feels a bit too much like gratuitous
code churn to me. <%= is what you use to output something, and you do want to
output a form, so <%= is what they should have stuck with from the beginning.

~~~
FooBarWidget
The inability to use <%= for form_for was a _limitation_ in ERB. Using <%= for
form_for to make things consistent is a _new feature_ since Rails 3. This has
got nothing to do with compatibility.

------
crazydiamond
RVM has been a boon. 1\. Easy to test my library/app against multiple ruby
versions.

2\. Easy to run an app which requires an older version of ruby (I typically
use 1.9.2).

Advanced features like gemsets allow finer grained control but only if needed.

~~~
Corrado
RVM is great for some things and a bane for others. Like you, I use it all
day, every day to build & test multiple Ruby projects on my MacBook. It has
really increased my output and reduced my hair-pulling.

On the other hand, automating and managing a server install using RVM is a
nightmare. I don't want/need compilers on my servers, I just want to push a
package out and have it work (i.e. APT).

~~~
herval
out of curiosity, what other issues does RVM pose to "others", other than
having to apt-get install compilers? also, wouldn't you need compilers anyway,
for a whole lot of gems that use native extensions?

~~~
fhars
No, that is the beauty of using system packages, you just apt-get install them
(if they are packaged, that is). That is why it is so important for projects
to make it easy for distributions to (re)package extensions.

------
tenderlove
At RubyKaigi, we talked about closing the Japanese list. It's a bad idea
because closing the list will not stop conversations from happening in
Japanese, it will just move the conversations to IRC. At least, if we have the
conversations recorded, there is an opportunity to translate them.

------
rb2k_
I just know that whenever I wanted to use the official ubuntu repository, I
ended up not being able to install a gem because rubygems was too old. Since
gem update --system doesn't seem to work on debian-based systems, I just had
to install it from source again

~~~
xiaomai
This wasn't a problem for a long time, but then a major release of release of
rubygems came out, and then the switch to gemcutter happened, etc. I've gotten
around this by installing everything but rubygems from the regular Ruby
packages from the Debian (or ubuntu) repos. I install the rubygems.org version
of rubygems and everything works great.

------
jhealy
I understand Lucas' decision, however it leaves some worrying questions about
the state of ruby on Debian systems.

Despite the rumours, the ruby1.8, ruby1.9 and rubygems packages are are
excellent shape thanks to the hard work by Lucas, Diago and Akira.

There were consistent fundamental workflow clashes between upstream and the
Debian packagers that have made their job exceedingly difficult. These clashes
aren't malicious or antagonistic, they're just the meeting of two very
different communities with very different priorities.

To name a few of the clashes: API changes in minor releases, effective forking
of rubygems by copying it into the 1.9 tree, opaque decision making (mostly
due to the language barrier), allowing installed programs (ie rubygems) to
update themselves and expectations on what is allowed in /usr/bin.

I'm not saying either community is necessarily correct on these issues, just
that they add up to some pretty big differences for debian-ruby to navigate.

I use the Debian packages for ruby1.8, 1.9.2, jruby and rubygems in both my
development and production environments. I've found them stable, rapidly
updated in response to security issues and predictable. Lucas - thanks for
your efforts, they will be missed.

------
wglb
A similar situation exists in Lisp. Most everyone I know downloads the lisp of
their choice (SBCL, CCL, Clojure) from the project site and goes forward from
there.

This seems particularly true of efforts that are cross-platform. In
particular, developing for Linux and Mac pretty much makes this the way to go
for these two languages.

------
now
Has anyone considered that crap like RubyGems, RVM, and Bundler is a symptom
of us as rapid (read: careless) developers not being able to manage our code
and our releases in an organized and well-ordered manner, not a symptom of
poor package management by distributions?

------
thmzlt
The same thing happened to Gentoo. I talked to the people behind Ruby packages
in Gentoo and they wanted to manually create packages for each gem. It is one
of the main reasons why I gave up on Gentoo and went back to Arch Linux.

I see gems as just snippets of code instead of "real" OS packages. They change
a lot, they are application specific, and (most of the time) they are simple.

~~~
davidw
> I see gems as just snippets of code instead of "real" OS packages. They
> change a lot, they are application specific, and (most of the time) they are
> simple.

And, like me, if you're using Rails, they are code that is visible to the
outside world. That is code that you want to make sure is secure, and is not
just some minor detail.

------
amacater
People - you forget that the Debian community is not just random packagers but
also developers. Debian packagers try VERY hard indeed to produce a stable
system that works out of the box for all of their users - and that includes
developers of all sorts with all types of development environment for several
common programming languages.

As part of that, it's useful to know what's stable and what isn't. Debian
tends to track version numbers and look for stable versions for a reason -
once released, Debian commits to supporting a release for the lifetime of that
release plus one year - roughly three years now. Anything that isn't actually
released as stable and thereby fixed will go into testing/unstable - there's
nothing to stop you running the latest and greatest at any time, but possibly
not on Debian stable.

In another life, I have to deal with developers who say to me: just mirror
Ruby and Rails for us on the inside of the corporate firewall. There isn't an
easy place to start - if you want to build a Ruby infrastructure inside a
large company, with software management systems, management suspicion of FLOSS
but committed developers - where do you begin to convince people that this is
a usable infrastructure?

Red Hat support a subset of very common packages and will support these now
for up to 10 years. That's your banks, stock exchanges, infrastructure
companies: if you want Ruby developers and programmers to make inroads into
that sort of environment, then you need sane packaging sense or at least a
sense of what's usable.

Debian produces a far larger subset for use of the programs out there - and on
13 hardware architectures.

As regards the English/Japanese language flaming: Debian has 1000 or so
developers and maintainers, spread worldwide - Lucas is a French speaker,
originally, but Debian developers speak and use most common human languages -
English is a convenience to a truly distributed, international community.

------
lusis
What would be nice is if RVM allowed a package option for an installed Ruby +
gemset. RVM doesn't work for me on my servers because it break idemopotence
but I'd love to install RVM on a testbed, type 'rvm package' and get a tarball
that I can dump in /opt/ on my production systems.

------
pkulak
I've never had very good luck using the Ubuntu Ruby packages. The binaries are
never linked, and I can't update Rubygems, which means I can't install a lot
of gems that I need. Is it tough to use RVM on a production server? Is it easy
to get Thin setup and all that?

------
netghost
So what is it that RubyGems does differently than other languages that makes
it so hard to support? Having a binary debian package for each ruby distro
makes sense (as an alternative to rvm), but I'm not really sure why gem is a
hindrance.

~~~
telemachos
The Rubygems package can be updated itself (normally) via `gem update
--system`. On Debian (and Debian-derived distros), this feature is disabled.

I believe their reasoning is that they don't want a package installed and
tracked via APT to be updateable outside of APT control and tracking.

~~~
kscaldef
CPAN can also self-update. So, why is Rubygems bad and CPAN presumably okay?

~~~
telemachos
I wondered about this myself as I wrote, but I wasn't 100% sure that CPAN
could self-update. I don't honestly know _why_ they're treated differently. (I
also wonder about cabal and pip and luarocks, etc. I just don't know.)

Corrado mentions here that he would like to see Ruby/gems handled more like
Perl/CPAN in Debian, but I'm not sure exactly what that means or what it would
look like.

~~~
kposehn
I read through all the comments to make sure no one else has responded. I'm
more of a Perl developer then a Ruby developer, but these are my observations
of the differences between the two.

1\. Perl Versioning is more thought out. It tends to have more consistent
versioning semantics. Experimental branches are done in odd minor versions.
e.g. 5.11.x was the development version; where 5.12.x is the stable release.
All further development occurs on 5.13.x, etc. Patch level changes on the
stable version are for minor updates (that don't break compatibility) or
security fixes. Major changes to the language that break things are enabled by
explicate pragams. E.G. use 5.10; Major version numbers represent core changes
to the language, and really represent a new language, that may or may not be
compatible with the previous language. E.G. Perl 5.X.x V.S. Perl 6.X.x. This
adherence to the value of having development and release versions trickles
down to the modules themselves.

2\. CPAN is both a tool and the Archive.

    
    
       a. As a tool it is great for both developers and package maintainers. 
    
           i. For developers:
    
              * it allow them to install bleeding edge modules.
    
              * easily upgrade those modules 
    
          ii. For maintainers it allows them to:
    
              * query the Archive for various meta information (dependences {build, release}, author, license, etc)
    
              * download the modules and extract them
    
              * allow the creation of build tools (e.g. dh-make-perl,pbuilder) that automate the packaging of the module
    
       b. As an Archive, it provides a common place with an agreed upon standard.
    
           i. Modules on CPAN can be marked as a Developer release.
    
          ii. Modules on CPAN can also be marked as released version.
    
         iii. All information in the Archive can be Queried by the CPAN module, that is part of Perl CORE
    
          iv. Perl Core, the interpreter and build tools are well defined.
    
           v. Core modules are also well defined, and do not change at patch levels.
    

So, package maintainers can easily package perl modules into their os specific
packaging system. To make a Debian package on Lenny from CPAN it's as simple
as: dh-make-perl --requiredeps --cpan Module::In::CPAN --build

If all your dependences are already in the system this will generate a deb for
you, if not it will tell you the modules it could not find; so you can build
them.

Perl modules allow you change where things are installed by respecting the
various PREFIX config options. From what I have read here, it seems this is
not true of RubyGems.

I don't know enough about RubyGems to know if it does the additional things
the CPAN tools does. But the main thing is Perl/CPAN works with Debian by
following their rules, and making it easy for them to build deb packages.

------
grimen
Evolution is key: Survival of the fittest, and RVM is the fittest in my
experience.

------
wccrawford
Whoa... Even though the developers of Ruby are Japanese, he's demanding that
they start speaking fluent English instead? And he thinks others are being
assholes?

Granted, he only said 'English' in his rant, but if it's typical Japanese
English then he won't understand it half the time anyhow, so it'd have to be
fluent English.

Here's a novel idea: FORK IT. If you don't like how a project is being run,
that's your option. Telling others how to do their work doesn't work with open
source. They don't have to listen to you, and calling them assholes certainly
doesn't help.

~~~
gwern
Telling someone to FORK IT is only useful if the maintainers are so incredibly
incompetent or toxic that even accepting the massive penalties of a fork
(especially massive for huge commercially popular projects) one is better off
with the fork.

Nowhere else. I don't want to live in a world where this is considered an
acceptable response to every small and big criticism or suggestion for
improvement:

"Hey, maybe we should remove that dead code."

"IF YOU DON'T LIKE DEAD CODE, FORK IT!"

"Have we considered moving to Git from our crufty old CVS?"

"IF YOU DON'T LIKE CVS UP, FORK IT!"

"Docbook really isn't very easy to contribute doc fixes to; I was thinking
about rewriting our manual in Markdown since it's really not that complex a
document - "

"FORK IT!"

~~~
dudus
It's very true. And if you decide to fork it than that's what you hear:

"OMG, YOU CAN'T FORK RUBY. ARE YOU CRAZY? THAT WOULD BE TERRIBLE."

~~~
jamesbritt

        It's very true. And if you decide to fork it 
        than that's what you hear:   "OMG, YOU CAN'T 
        FORK RUBY. ARE YOU CRAZY? THAT WOULD BE TERRIBLE."
    
    

Or not:

[http://pragdave.blogs.pragprog.com/pragdave/2008/12/forking-...](http://pragdave.blogs.pragprog.com/pragdave/2008/12/forking-
rubymy-rubyconf-keynote-is-now-up.html)

