I didn't see the words "bug report" anywhere there. Debian is a volunteer organization, open to anyone. If you want to improve it, sign up and help instead of just ranting about crazy paranoid theories like:<p>> It's simply a tactic to make sure that you are stuck on Debian.<p>Of course I'm biased, as I'm a former Debian maintainer, but I think that Zed's connection with the reality of the situation is tenuous, at best, in this case.<p>Making a distribution is difficult, and doing so with 1000's of volunteers who are not working on it full time (and since you're not paying for it, they don't really owe you anything) and are distributed throughout the world adds to the difficulty, so yes, there are bugs and problems and challenges to overcome. That said, if each author of each package in Debian got their way about the exact location of files and so forth, the system would be utter chaos. If you think your package isn't being treated right in Debian, get on the mailing list, file a bug report, make your case, and get things fixed, rather than treating Debian as "the enemy"... Sheez.
> But here's the problem, Debian package maintainers don't want to give up control to the responsible parties. I would more than gladly make my own .deb packages, but they refuse to let me. In fact, I plan on making packages for the major Unices in order to head them off. That's what everyone ends up doing.<p>As a user, and amateur administrator of my home machines, I've learned the hard way that third-party packages supplied by the original software vendor are, in general, utter crap. They're built against a distro two or three versions old; or they're built for Mandrake or Ubuntu instead of Red Hat or Debian; they "install" a tarball to /tmp which the post-installation script untars in the root directory; they don't have any dependencies declared at all but crash at startup if you don't have a particular version of libjpeg... if you're relying on the packaging system to detect file conflicts or outdated dependencies, third-party packages can be very, very scary.<p>The single biggest reason I choose Debian (and sometimes Ubuntu) is the uniformly high-quality packaging. Zed's found one problem package, and a trawl through Debian's bug tracker will no doubt find others, but the fact of the matter is that with a single command I can install almost any Free software in the world, and have it installed and set up within seconds - and Debian has years of experience figuring out how to make that work. I don't think that's a thing to be dismissed lightly.
This is in no way specific to Ruby — if you look at the way any sufficiently advanced software you're familiar with is packaged in Debian, you'll find it to be completely fucked. Ancient versions, nonstandard configuration files, random things disabled at compile-time (often for ideological reasons), files scattered everywhere with the new locations hardcoded, with basic features broken into separate packages. My favorite is the random patches, which when they aren't in the service of the aforementioned ridiculousness, are mostly cherry-picked from current upstream versions to 'fix bugs' without accidentally introducing features because they're afraid of new version numbers. When a patch doesn't fit those categories you really have to worry, because now they're <i>helping</i> (see OpenSSL)<p>The result is that any program or library that you use directly must be sourced from upstream, <i>especially</i> if it's less than 15 years old or written in a language other than C or C++. Luckily pretty much all of the modern programming language environments have evolved to cope with this onanistic clusterfuck.<p>Haskell has more fucked by Debian than any other language I know of — when I last had to deal with it a year ago there were two broken+old builds of GHC with different package names and mutually-exclusive sets of packages that depended on them. On top of that the version of cabal (Haskell's packaging tool) in the repository was so far out of date that you couldn't use it to build anything remotely recent (including useful versions of itself), nor could you use it with anything in Hackage (the central repo).<p>My old roommate had listened to me bitch about this stuff for years, and always dismissed me as crazy for thinking that the packaging was fucked (though he did share my hate of <i>debian-legal</i>). Last week he called me out of the blue and apologized — he'd installed Wordpress through Debian and they'd broken it up into a bunch of library packages, but still left a base skeleton of random php files and symlinks, accomplishing nothing but breakage and unportability.
Here is my beef with Debian.<p>A lot of the software they package comes with unit tests. Those unit tests have a purpose. They are meant to see whether or not the software as configured and installed, works.<p>Debian systematically strips those unit tests out, and <i>never</i> runs them to see how much stuff they are shipping already broken. Why? Why not package the unit tests as an optional package, and make sure they have a wide variety of systems in different configurations running them to notice problems?<p>I can't count how many times I've tried to install a Perl module from CPAN, found it was failing its unit tests, installed the Debian package with it, ran the unit tests, and found that the unit tests said the package, as installed, was broken. It's not as if the package developer didn't try to tell you you were missing something. Why throw that information away?<p>If they did this then they'd automatically catch a lot of problems that currently get missed. Heck, insert a test for ruby gems that says, "Does this software start?" They'd have caught this bug automatically.<p>Until Debian catches up with standard best practices, I completely can't agree with the meme that they run software better than everyone else. It isn't as if unit testing is a new idea. It has been pretty mainstream for most of the last decade. Some were doing it earlier. Perl has been doing it since the 1980s.
...and people ask me why I write tons of freeware, but make so little of it open source.<p>The reason is simple: control. If I can't control every stage of the development, deployment, and distribution process, I don't want in (yes, I'm a control freak. No, I don't think necessarily a blemish on my personality, it's just who I am). If there's something wrong with how my users perceive my software, it's because of something _I_ did wrong, not because someone took my hard work and toil and perverted it with their own changes, be it making the code ugly with nasty function names or dirty hacks (in my opinion, of course) or if they distribute it in a way that makes users cringe. It's my hard work, and I deserve to be (a) in control of the user experience, and (b) attributed.<p>If you're willing to make your awesome utility/code that you've spent 5 years developing and maintaining fully available to the public, giving up all control of the end-users' perception of the package, you have a bigger heart than me. But me, I'm a selfish guy when it comes to my users, and I don't want anyone to even have the possibility of hurting them. I have _my_ users' best interest at heart, you probably don't. At least, not to the same extent that I would.
I sympathize with frustration at poor software packaging, but the proposed solution seems completely disproportionate to the offense. I also don't see any real evidence presented for the assertion that Debian's policies are based on a corrupt motive. What OS is actually pure and innocent of technical flaws and bad policies? If I recall, openSuse is in bed with Microsoft, Ubuntu fails to contribute code to important projects, Fedora is really just Red Hat's beta testing, etc. One of the pains of open source software is that things you write will probably be messed up in lots of ways by other people. If seeing software packaged or modified in ways you don't like makes you angry and advocate retaliation, is that really consistent with the philosophy of a free software license?
I've always thought that it was a bad idea for Linux distros to package any language libraries at all. It seems like a lot of repeated work and your users will probably end up needing to install things manually in the end. Things will require the lastest version of gems, new and essential features will be added, etc. Just give your users a manual on how to install gems (or pip, or whatever) and let it be. The users of language libraries are exclusively programmers after all; I think it's safe to assume they can handle library installation.<p>That said, Zed is blowing this way out of proportion.
Actually, the Ruby and Rubygems Squeeze packages have been in quite a flux lately. One of the more recent Ruby1.9.1 packages broke Rubygems completely due to some changes in the Ruby 1.9.2 source and they way they handle gems. The latest version of Ruby has really integrated the Gem package management system into its core. It has therefor been decided to stop building a separate Rubygems package for the 1.9.x series and let the Ruby1.9.x package deal with gems.<p>Have their been clashes between the Ruby and Debian communities? Yes! Are we all working toward a solution? Yes! Will it happen instantly? Unfortunately no, but I think the two groups are now talking and are making some good progress. Keep an eye out for some good stuff in the future.
[Disclaimer: I'm not a Ruby developer, but have developed in plenty of languages, as well as being a sysadmin for a fair while]<p>IME, separate package-management for each and every language is more painful than the problem he is describing.<p>Rubygems, CPAN, whatever other languages use.<p>As soon as you install things outside of the distro package-manager, it has no idea what is going on with those packages and so continues to think that they aren't installed. If there was a way to get the package-managers for language libraries and the distro to play together nicely and work for dependencies etc then this would be OK, but as it is it's a bit of a sysadmin nightmare.<p>Edit: I thought that installing distro-supplied packages into /usr/local was against the FHS?
It might be worth re-evaluating this rant in the light of Lucas Nussbaum's (Debian Ruby maintainer) recent "mythbusting and FAQ" post:<p><a href="http://www.lucas-nussbaum.net/blog/?p=566" rel="nofollow">http://www.lucas-nussbaum.net/blog/?p=566</a>
I think there is an important point here. Debian has a lot of control, and takes very little responsibility. A similar situation:<p><a href="http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=380731" rel="nofollow">http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=380731</a>
Hypothetical question: Now that rvm has been created, would anyone still use apt-get to install ruby even if the latest version was supported?<p>Sure you could argue that yes, ruby should be installed with apt-get and alternative versions should be handled with Debian's alternatives infrastructure...<p>I think this is an interesting case in which version numbers are more than just version numbers, they are more like sister projects, and they don't fall neatly into the "conservative and stable" or "bleeding edge and risky" camps the way maintainers typically view different versions.<p>From the perspective of a package maintainer, if we had to include an alternatives list for every dot version of every package, then the distro would explode in complexity.<p>Ruby and Python just happened to grow so quickly that their growth didn't immediately trigger the appropriate response from distro maintainers, and very quickly the community worked around the problem.
Obviously, he should spend just a few hours in the shoes of a package manager. Honestly. What would it be without packages/ports? A mess.<p>The only people trying to make it bearable here are the package/ports managers and yet they don't get any kind of reward for their job. They have to come up with crazy tricks to make things just work because people who write software are unable to write proper install notes, list dependencies correctly, etc..<p>This process is heavy, slow and doesn't always produces the expected results (there's no doubt about it). So people thought it would be great to have just language-specific package management systems and make it unbearable again. Alright. I personally never use them and install stuff at hand unobtrusively.<p>Now, do your job. Go fill a bugreport. Or better yet; fork. This is not discussing things, this is not helping. Tears don't help.
I have never used gentoo. Does gentoo patch packages as much as Debian? Or is their build process sophisticated to allow parallel install of multiple versions of say postgresql?
You know, maybe somebody would want to know the Debian POV on this issue:<p>* <a href="http://www.lucas-nussbaum.net/blog/?p=566" rel="nofollow">http://www.lucas-nussbaum.net/blog/?p=566</a><p>* <a href="http://www.lucas-nussbaum.net/blog/?p=575" rel="nofollow">http://www.lucas-nussbaum.net/blog/?p=575</a><p>Debian is all about stability and volunteer effort.<p>Whining is not going to fix things.
This is an Ubuntu package problem, not Debian. In case you didn't notice, Ubuntu is built from a snapshot of Debian /unstable/. They call it unstable for a reason, I guess.<p>On Debian stable "aptitude install rubygems" followed by "gem install rake" just works. This looks like a completely gratuitous rant, I've seen Jed Shaw better inspired.