10 ms·

Making Debian Responsible For Its Actions

84 points by alexkay 16y ago

davidw 16y ago
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: > It's simply a tactic to make sure that you are stuck on Debian. 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. 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.
- wtn 16y ago
  Of course Zed's hyperbole is rampant but that's what makes him fun to read. I thought his Microsoft blast was hilarious. The way Debian attempts to micromanage rubygems is insane and ends up breaking under real world environments. Why do they persist?
  - davidw 16y ago
    > Of course Zed's hyperbole is rampant but that's what makes him fun to read. Does he want to be 'fun to read' or fix a problem? Because pissing all over other people's hard work and attributing nefarious motives to them to boot is not a good way of fixing the problem. > The way Debian attempts to micromanage rubygems is insane and ends up breaking under real world environments. Why do they persist? Good question - why not do some research and find out? (BTW, I'll add that there are good reasons not to use Debian's gem packages, and that I disagree with the 'pile-on' downvoting of the parent post, even if I disagree with what he said)
    - regularfry 16y ago
      Being fun to read gives him a disproportionately large audience, which increases the chances of things getting fixed.
      - gloob 16y ago
        So would filing a bug report.
        FooBarWidget 16y ago
        It would not. The Debian maintainers created the status quo deliberately. Causing a stir would be far more effective than another bug report.
  - rbanffy 16y ago
    > Why do they persist? Because they have a systemwide mechanism for doing precisely the same thing rubygems is trying to do with Ruby, that system has been in place longer than Ruby itself and has proven to be one of the major strengths not only of Debian, but, in similar implementations, of all Linux distros. We have explored this before - if Zed wants a Ruby that works his way, he should install a separate one, like Python developers do with virtualenv or a source tarball. Then his gems will be, hopefully, installed somewhere sane out of the way of update the system. If gem installs its libraries on the wrong place then, it's a bug with gem, not Debian.
- JoachimSchipper 16y ago
  There is a reason that Debian is being singled out, which you ignore - Debian likes to add lots of distribution-specific patches to everything they package. Other OSes/distributions are not as problematic, because they are much more likely to ship software as the author wrote it (unless it's ridiculously broken and unmaintained and important.) Also: why should software authors have to write bug reports to Debian?
  - davidw 16y ago
    With 1000's of packages, and 1000's of maintainers, saying that "Debian" likes to patch "everything" is a pretty big claim. A lot of the patches that do go in make whatever package integrate better with the rest of the system. > Also: why should software authors have to write bug reports to Debian? Because there's a bug? > "Even though the piece of software I asked aptitude to install requires these libraries to run, they refuse to install it." At first glance, that sounds like a packaging bug to me, with Rubygems, not with one of Zed's packages. The best thing to do in those cases is report the bug, rather than attempt to "make Debian pay" (for the thousands and thousands of hours of work to give you a free operating system, presumably?)
    - yourmomcalled 16y ago
      I believe, yes, Zed Shaw is trying to make a big claim. Reread the original post and you will see that he does in fact accuse them of liking to patch everything because they like control and lockin. Will you do me a favor and file this bug report for me? I'm allergic to sanctimony which I'm sure is all you'll receive from the package maintainer: "gem update --system is disabled on Debian. RubyGems can be updated using the official Debian repositories by aptitude or apt-get."
      - davidw 16y ago
        > control and lockin. That's a pretty absurd claim. Is there anything to back it up? I mean, releasing an open source operating system doesn't seem to be the epitome of "control and lock in" to me. Ubuntu probably wouldn't exist if Debian were any good at "control and lock in", for one. Also, your "bug report" is quite different than the one Zed points out. You're suggesting a fundamental change to the way rubygems works on Debian. That's something that merits further discussion, rather than a simple "bug report", obviously.
- perlgeek 16y ago
  I can only agree. If something doesn't work, and you think debian has screwed it up, type reportbug rubygems and write up what's wrong. It often takes quite some time to fix stuff, but often it is fixed eventually. (Note that by Debian policy, dependencies that are only for some actions of the module might not be hard dependencies, but "recommends" dependencies; but you can configure apt-get/aptitude to install those for you too).
- lyudmil 16y ago
  Okay, I can absolutely appreciate how hard making a distro is. Point taken. However, your comment also indicates exactly what Zed was furious about. Debian is a piece of software that people depend on. They have a right to be upset when there are bugs. The proper response is to apologize and fix the bug. Period. Instead, your response is to blame the (already angry) user on the basis that they didn't submit a bug report. I would be livid if you responded that way. Yes, you do voluntary work. You get credit when you do good work. It's only fair that you take on the responsibility when your work isn't so good. The Debian community can consider Zed's post a bug report. Now, go fix it please.
  - davidw 16y ago
    Sorry, Debian is not telepathic, so while yes, they should fix the bug, if it hadn't been reported, they couldn't have fixed it. It's absolutely the proper thing to do to file a bug if you find one. That's not "blaming the user". Also, "I'm imagining a mass petition, maybe some funny ad campaigns, in-person confrontations meant to embarrass package maintainers, SEO tricks to get people off Debian, promotion of any alternative to Debian, anything to make them pay, apologize, and listen." is not something likely to make most people apologize, fix the problem and move on. It's rude and uncalled for.
    - tjogin 16y ago
      The "bug" in question is not unknown to them. Especially the distribution of Ruby and Rubygems is completely botched. The most common answer in #rubyonrails is probably this: "you've installed ruby/rubygems via apt haven't you? uninstall it and reinstall it manually."
      - davidw 16y ago
        Actually, what he says is "Gems can't even run because the gems needs openssl and net/scp, but the Debian (not Ubuntu) package doesn't install it along with rubygems.", which means that there is likely a missing dependency: rubygems should require ruby-ssl. Of course, the more general point stands that the current state of the Debian/rubygems integration is far from ideal. However, fixing it takes people thinking about the problem and working on it, not just moaning and calling for boycotts. What a pissy attitude: it's easy to say "this sucks!", but much harder to create something better, or fix the broken thing. I would have been quite comprehending of a "I'm very frustrated by X, Y, and Z about Debian". I mean, it certainly has its flaws (I ended up moving to Ubuntu myself). Another thing is this entitled attitude of "let's hurt them!"
- regularfry 16y ago
  Fixing the "bug" involves breaking either the FHS or rubygems. My belief is that rubygems is broken by design, but actually going from there to having a replacement that works with apt is a lot of work. Fortunately, this is being worked on. I won't say by whom, because I don't know if they want it public yet.
  - blasdel 16y ago
    The approach that rubygems works terrifically, and is depended upon by the Ruby community — you can trivially install as many versions of the same gem as you want to satisfy the dependency requirements of other gems and apps. Library authors can fix mistakes and take advantage of new functionality in other libraries without worry. Everything about Debian's approach is in rabid opposition to this. They want to scatter the files all over their precious FHS. They want to install as few versions of libraries as possible, and where multiple versions must be installed in the best case the names sre mangled because apt does not have a 'slots' mechanism (average case they use the mediocre 'alternatives' system, worst case there are multiple independent depgraphs!). On top of all of that there's their release cycle where they freeze all the packages at a particular version number for several years for normal users (and regular 3-6 month periods on the 'bleeding edge'), after which they start mutilating random patches from upstream as 'support' instead of just shipping the new versions. You're right that there's no way to reconcile this fundamental schism. You're wrong about which community is breaking everything.
    - __david__ 16y ago
      > Everything about Debian's approach is in rabid opposition to this. This is not necessarily true. There are many Debian packages that can be installed in parallel. I still have gcc-2.95 installed and that hasn't been available in the Debian archive for years. It is named properly and doesn't conflict with any of the newer gccs. So it is possible to make parallel installs. > They want to scatter the files all over their precious FHS. This is true. And as a Debian user, I support them fully. I don't want to learn some stupid Ruby package directory convention. I already know if I install a Debian package that the configuration files go in /etc/packagename and the docs are in /usr/share/doc/packagename. Every package is like that and consistency is a good thing. I think the Debian Perl maintainers have gotten this right. They have a program "dh-make-perl" that will download a CPAN package and make it into a Debian package. This really gets you the best of both worlds. Hopefully something like that will get written for Python and Ruby (they haven't had their CPAN clones out for as long as CPAN, so give it time). > On top of all of that there's their release cycle where they freeze all the packages at a particular version number for several years for normal users. That's not just a Debian thing. %$#@! RHEL still ships a 2.6.18 kernel in their latest release! There is a certain class of people who are very, very conservative with their software upgrades. Debian Stable and RHEL appeal to those types. If you aren't one of those types, don't run them--instead run Debian Unstable or Fedora or Ubuntu. Those stay on the bleeding edge most of the time.
- heresy 16y ago
  Debian doesn't really work too well when you need multiple or new versions of software, or need something custom. It's either spend a week wrapping your head around all the different ways of getting something to spit out a conforming .deb, or falling back to something like RVM + RubyGems / PIP. The maintainer community is also reflexively defensive when they've broken something. The problem is never Debian breaking things into little unusable pieces, it's always upstream for not foreseeing how their software would be bastardized on Debian.
  - davidw 16y ago
    > Debian doesn't really work too well when you need multiple or new versions of software, or need something custom. That's a fair complaint, and is also something of a complex issue, as there are tradeoffs between high quality integration, rapidly assimilating new stuff, the total number of packages in the repository, and so on. However, Zed's mistruths about the nature of Debian (which is a volunteer-drive non-profit organization, not a business), are not: "It is sadly pure business and has nothing to do with open source, quality, or culture." "I did not write it to boost the Debian business plan"
    - heresy 16y ago
      I think the story of "forking" system packages for local use needs improvement. And for all Debian's adherence to standards, it's unfortunate that one couldn't be agreed upon for source packages, 'apt-get source' is a mixed bag. This makes it a royal pain to maintain forks, because now you have to be up on three or four source packaging formats, in addition to getting the final binary format to comply with the standards. For the parts of the system where you don't care, using the distributor provided packages is fine. But when you do care, it is often simpler to just use pristine upstream rolled into your own deb as a starting point for managing package versions at your site.
      - blasdel 16y ago
        It's like the mainstream news media — anytime they report on a subject you know anything about, it's riddled with obvious errors. After this happens enough times, you know enough not to trust them about other subjects…
- gaius 16y ago
  Agreed 100%. He even says "the Debian business plan" - what plan is that!? Does Zed even know what Debian is? They aren't Red Hat!
- FooBarWidget 16y ago
  You are under the impression that Debian doesn't know about this problem or that they consider the current behavior to be a bug. Both are untrue. The current behavior is very much an explicit choice by Debian and no amount of bug reporting or patch submitting will change the situation.
grandalf 16y ago
Hypothetical question: Now that rvm has been created, would anyone still use apt-get to install ruby even if the latest version was supported? Sure you could argue that yes, ruby should be installed with apt-get and alternative versions should be handled with Debian's alternatives infrastructure... 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. 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. 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.
- davidw 16y ago
  > would anyone still use apt-get to install ruby even if the latest version was supported? Not everyone is a heavy Ruby user - someone might just want to install a package that depends on Ruby and be sure that things work. Just as they may want to install a package that depends on Java, Ada, Haskell, Erlang, Perl, Python, PHP, Ocaml, Tcl or any of the many other languages present in Debian, and not have to deal with a different package management system for each language on the computer. > Ruby and Python just happened to grow so quickly that their growth didn't immediately trigger the appropriate response from distro maintainers It's actually a fairly old problem. Perl and CPAN have many of the same issues. I'm not sure there's a perfect solution.
- prodigal_erik 16y ago
  apt-get or yum for ruby? Hell yes. After wasting countless hours on random versions of crap scattered around some servers' filesystems but not others, now nothing hits production without being in a package that installs and uninstalls cleanly and declares everything it relies on being present. That includes my own code, which we package ourselves.
  - __david__ 16y ago
deleted 16y ago
[deleted]
poet 16y ago
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. That said, Zed is blowing this way out of proportion.
- davidw 16y ago
  > Just give your users a manual on how to install gems (or pip, or whatever) and let it be. Uh... that might work for one language, but for 10? 20? And some poor sysadmin is supposed to use all these disparate tools to install security fixes too? And you're forgetting that there are "end-user" programs that depend on those libraries as well, so they really do need to be packaged up. > That said, Zed is blowing this way out of proportion. That goes without saying.
  - poet 16y ago
    And you're forgetting that there are "end-user" programs that depend on those libraries as well, so they really do need to be packaged up. I'm not forgetting this. I don't think the user's programs should use the same libraries (or even the same language install) that the distro's programs depend on. This way, if the user messed something up (like trying to upgrade a library), the entire distro wont be hosed. It's a really bad idea from a stability, security, and design standpoint if you don't keep these two things separate.
Corrado 16y ago
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. 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.
mycroftiv 16y ago
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?
- blasdel 16y ago
  The efforts of both Zed and Debian are based on the same corrupt motive: self-satisfaction As the upstream developer, Zed wants to make sure that his software is distributed in a manner that is useful to people and actually works and shit. This gives him jollies. As the distributors, the Debian contributors want to fullfil ideological goals, fit everything into their neat hierarchy, assuage neckbeard sysadmins that the version number is sufficiently ancient (not that the software is, given the distro patches), pretend to care about people running it on the PA-RISC port of Debian GNU/kFreeBSD, wank about licensing, and reach consensus. This gives self-important teenagers and manchildren all kinds of joillies.
  - Mod_daniel 16y ago
    I can't believe this getting upvoted. I wonder how much software you use every single day thats created and maintained by "self-important teenagers and manchildren".
mgunes 16y ago
It might be worth re-evaluating this rant in the light of Lucas Nussbaum's (Debian Ruby maintainer) recent "mythbusting and FAQ" post: http://www.lucas-nussbaum.net/blog/?p=566 http://www.lucas-nussbaum.net/blog/?p=566
- auxbuss 16y ago
  This is far from being a rant. It's a concise exposition on the Debian/Ruby issues. Thanks for posting the link, but being labelled a rant, I nearly didn't go there. Just want to encourage others to read it for an excellent explanation of the issues at hand from the guy who is doing the work.
  - telemachos 16y ago
    I'm pretty sure that "this rant" in the parent refers to Zed's post not Lucas's. The parent's point being "we should look at Zed's rant again after reading this discussion by a Debian Ruby maintainer."
    - mgunes 16y ago
      Exactly.
legooolas 16y ago
[Disclaimer: I'm not a Ruby developer, but have developed in plenty of languages, as well as being a sysadmin for a fair while] IME, separate package-management for each and every language is more painful than the problem he is describing. Rubygems, CPAN, whatever other languages use. 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. Edit: I thought that installing distro-supplied packages into /usr/local was against the FHS?
- davidw 16y ago
  > way to get the package-managers for language libraries and the distro to play together nicely and work for dependencies etc Yes, hacking the language's package manager to talk to the distribution package manager is probably the only way to really go about solving the problem in an elegant way, and even that is not without its pain points.
  - legooolas 16y ago
    > pain points Absolutely, but this problem has been around for a long time, and fighting with distributions on how to get it to work won't help anyone. Of course, it also means that if you install a buggy version of a library from, say, CPAN then you could break distro-supplied packages... I guess it depends on which you value more: distributor-provided testing or being able to install out-of-band packages onto your distribution more easily and with proper dependencies.
pbiggar 16y ago
I think there is an important point here. Debian has a lot of control, and takes very little responsibility. A similar situation: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=380731 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=380731
- protomyth 16y ago
  wow, just wow. You would think that if you volunteer to maintain something, you would actually like what you are maintaining.
blasdel 16y ago
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 helping (see OpenSSL) The result is that any program or library that you use directly must be sourced from upstream, especially 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. 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). 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 debian-legal). 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.
ComputerGuru 16y ago
...and people ask me why I write tons of freeware, but make so little of it open source. 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. 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.
- VMG 16y ago
  You could still make it open source but craft the license in a way to prevent redistribution
  - davidw 16y ago
    > You could still make it open source but craft the license in a way to prevent redistribution Then it would not be open source.
    - kleiba 16y ago
      Of course it would, but it would not be free software.
      - davidw 16y ago
        "open source" has a precise definition, and doesn't just mean "you get the source code": http://en.wikipedia.org/wiki/Open_Source_Definition http://en.wikipedia.org/wiki/Open_Source_Definition
thristian 16y ago
> 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. 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. 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.
- aw3c2 16y ago
  I read the first sentence, did not notice it was a quote and downvoted you. Sorry!
- bad_user 16y ago
  I used Debian on the desktop for 2 years (2008-2009) ... the whole time the Iceweasel package (their repackaged Firefox) has had its renderer broken, making some web pages unusable for me ... this wasn't a problem if I manually downloaded and installed Firefox, and it finally got fixed just before I switched to Ubuntu. It does have the best software repository ever, but boy how much it sucks when something's broken.
- JoachimSchipper 16y ago
  Third-party binaries suck, but you can compile from source, you know...
nakkiel 16y ago
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. 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.. 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. 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.
wazoox 16y ago
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. 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.
btilly 16y ago
Here is my beef with Debian. 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. Debian systematically strips those unit tests out, and never 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? 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? 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. 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.
- __david__ 16y ago
  I don't think it's so cut and dry. In the ideal case, the packages don't need tests because they are going into the system already tested. If the package is correct then running the unit tests is just redundant work because you are getting an identical copy of a package that already tested good with the appropriate dependencies. I think that's the theory anyway. On the other hand, theory does not always match reality. Debian CPAN packages do run the unit tests--they just run them when you create the package and not when you install the package. In fact, the package will not build unless the tests pass.
  - btilly 16y ago
    Sorry, but it really is that cut and dry. In the ideal case you don't need unit tests. In the real world, they are useful. One of the big things that unit tests are supposed to catch are hidden dependencies. By nature, hidden dependencies are likely to be installed on the maintainer's machine, so unit tests only help if they are run somewhere else. As a prime example, the bug that Zed was complaining about was a dependency problem of EXACTLY this sort. It worked fine on the maintainer's machine. It didn't work on Zed's machine because he didn't have a key library installed. No unit test the maintainer can run would catch this. Even a stupid unit test Zed can run would have flagged this immediately. Incidentally about the Debian CPAN packages, my experience with them a few years back was that they were so consistently broken (usually because of locale issues) that I have a hard time believing that unit tests had actually been run by anyone. Or if they were, they were ignored.
xinuc 16y ago
I'm okay with Debian packages, unless someone include locusts as dependency http://xkcd.com/797/ http://xkcd.com/797/
whatajoke 16y ago
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?
- blasdel 16y ago
  Gentoo avoids making patches specific to itself wherever possible, when it does it's generally just to make it compile+work, the changes are straightforward, and they are applied live on your machine in a self-documenting way. The build process is also sophisticated enough to be able to 'slot' potentially-incompatible versions of the same package so that they can be installed simultaneously. From my recent snapshot of the package repo I can install 5 different simultaneous major versions of postgres, with a variety of independent build options.
mariana 16y ago
You know, maybe somebody would want to know the Debian POV on this issue: * http://www.lucas-nussbaum.net/blog/?p=566 http://www.lucas-nussbaum.net/blog/?p=566 * http://www.lucas-nussbaum.net/blog/?p=575 http://www.lucas-nussbaum.net/blog/?p=575 Debian is all about stability and volunteer effort. Whining is not going to fix things.

84 points by alexkay 16y ago

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: > It's simply a tactic to make sure that you are stuck on Debian. 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. 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.

wtn 16y ago
Of course Zed's hyperbole is rampant but that's what makes him fun to read. I thought his Microsoft blast was hilarious. The way Debian attempts to micromanage rubygems is insane and ends up breaking under real world environments. Why do they persist?
- davidw 16y ago
  > Of course Zed's hyperbole is rampant but that's what makes him fun to read. Does he want to be 'fun to read' or fix a problem? Because pissing all over other people's hard work and attributing nefarious motives to them to boot is not a good way of fixing the problem. > The way Debian attempts to micromanage rubygems is insane and ends up breaking under real world environments. Why do they persist? Good question - why not do some research and find out? (BTW, I'll add that there are good reasons not to use Debian's gem packages, and that I disagree with the 'pile-on' downvoting of the parent post, even if I disagree with what he said)
  - regularfry 16y ago
    Being fun to read gives him a disproportionately large audience, which increases the chances of things getting fixed.
    - gloob 16y ago
      So would filing a bug report.
      - FooBarWidget 16y ago
        It would not. The Debian maintainers created the status quo deliberately. Causing a stir would be far more effective than another bug report.
- rbanffy 16y ago
  > Why do they persist? Because they have a systemwide mechanism for doing precisely the same thing rubygems is trying to do with Ruby, that system has been in place longer than Ruby itself and has proven to be one of the major strengths not only of Debian, but, in similar implementations, of all Linux distros. We have explored this before - if Zed wants a Ruby that works his way, he should install a separate one, like Python developers do with virtualenv or a source tarball. Then his gems will be, hopefully, installed somewhere sane out of the way of update the system. If gem installs its libraries on the wrong place then, it's a bug with gem, not Debian.
JoachimSchipper 16y ago
There is a reason that Debian is being singled out, which you ignore - Debian likes to add lots of distribution-specific patches to everything they package. Other OSes/distributions are not as problematic, because they are much more likely to ship software as the author wrote it (unless it's ridiculously broken and unmaintained and important.) Also: why should software authors have to write bug reports to Debian?
- davidw 16y ago
  With 1000's of packages, and 1000's of maintainers, saying that "Debian" likes to patch "everything" is a pretty big claim. A lot of the patches that do go in make whatever package integrate better with the rest of the system. > Also: why should software authors have to write bug reports to Debian? Because there's a bug? > "Even though the piece of software I asked aptitude to install requires these libraries to run, they refuse to install it." At first glance, that sounds like a packaging bug to me, with Rubygems, not with one of Zed's packages. The best thing to do in those cases is report the bug, rather than attempt to "make Debian pay" (for the thousands and thousands of hours of work to give you a free operating system, presumably?)
  - yourmomcalled 16y ago
    I believe, yes, Zed Shaw is trying to make a big claim. Reread the original post and you will see that he does in fact accuse them of liking to patch everything because they like control and lockin. Will you do me a favor and file this bug report for me? I'm allergic to sanctimony which I'm sure is all you'll receive from the package maintainer: "gem update --system is disabled on Debian. RubyGems can be updated using the official Debian repositories by aptitude or apt-get."
    - davidw 16y ago
      > control and lockin. That's a pretty absurd claim. Is there anything to back it up? I mean, releasing an open source operating system doesn't seem to be the epitome of "control and lock in" to me. Ubuntu probably wouldn't exist if Debian were any good at "control and lock in", for one. Also, your "bug report" is quite different than the one Zed points out. You're suggesting a fundamental change to the way rubygems works on Debian. That's something that merits further discussion, rather than a simple "bug report", obviously.
perlgeek 16y ago
I can only agree. If something doesn't work, and you think debian has screwed it up, type reportbug rubygems and write up what's wrong. It often takes quite some time to fix stuff, but often it is fixed eventually. (Note that by Debian policy, dependencies that are only for some actions of the module might not be hard dependencies, but "recommends" dependencies; but you can configure apt-get/aptitude to install those for you too).
lyudmil 16y ago
Okay, I can absolutely appreciate how hard making a distro is. Point taken. However, your comment also indicates exactly what Zed was furious about. Debian is a piece of software that people depend on. They have a right to be upset when there are bugs. The proper response is to apologize and fix the bug. Period. Instead, your response is to blame the (already angry) user on the basis that they didn't submit a bug report. I would be livid if you responded that way. Yes, you do voluntary work. You get credit when you do good work. It's only fair that you take on the responsibility when your work isn't so good. The Debian community can consider Zed's post a bug report. Now, go fix it please.
- davidw 16y ago
  Sorry, Debian is not telepathic, so while yes, they should fix the bug, if it hadn't been reported, they couldn't have fixed it. It's absolutely the proper thing to do to file a bug if you find one. That's not "blaming the user". Also, "I'm imagining a mass petition, maybe some funny ad campaigns, in-person confrontations meant to embarrass package maintainers, SEO tricks to get people off Debian, promotion of any alternative to Debian, anything to make them pay, apologize, and listen." is not something likely to make most people apologize, fix the problem and move on. It's rude and uncalled for.
  - tjogin 16y ago
    The "bug" in question is not unknown to them. Especially the distribution of Ruby and Rubygems is completely botched. The most common answer in #rubyonrails is probably this: "you've installed ruby/rubygems via apt haven't you? uninstall it and reinstall it manually."
    - davidw 16y ago
      Actually, what he says is "Gems can't even run because the gems needs openssl and net/scp, but the Debian (not Ubuntu) package doesn't install it along with rubygems.", which means that there is likely a missing dependency: rubygems should require ruby-ssl. Of course, the more general point stands that the current state of the Debian/rubygems integration is far from ideal. However, fixing it takes people thinking about the problem and working on it, not just moaning and calling for boycotts. What a pissy attitude: it's easy to say "this sucks!", but much harder to create something better, or fix the broken thing. I would have been quite comprehending of a "I'm very frustrated by X, Y, and Z about Debian". I mean, it certainly has its flaws (I ended up moving to Ubuntu myself). Another thing is this entitled attitude of "let's hurt them!"
regularfry 16y ago
Fixing the "bug" involves breaking either the FHS or rubygems. My belief is that rubygems is broken by design, but actually going from there to having a replacement that works with apt is a lot of work. Fortunately, this is being worked on. I won't say by whom, because I don't know if they want it public yet.
- blasdel 16y ago
  The approach that rubygems works terrifically, and is depended upon by the Ruby community — you can trivially install as many versions of the same gem as you want to satisfy the dependency requirements of other gems and apps. Library authors can fix mistakes and take advantage of new functionality in other libraries without worry. Everything about Debian's approach is in rabid opposition to this. They want to scatter the files all over their precious FHS. They want to install as few versions of libraries as possible, and where multiple versions must be installed in the best case the names sre mangled because apt does not have a 'slots' mechanism (average case they use the mediocre 'alternatives' system, worst case there are multiple independent depgraphs!). On top of all of that there's their release cycle where they freeze all the packages at a particular version number for several years for normal users (and regular 3-6 month periods on the 'bleeding edge'), after which they start mutilating random patches from upstream as 'support' instead of just shipping the new versions. You're right that there's no way to reconcile this fundamental schism. You're wrong about which community is breaking everything.
  - __david__ 16y ago
    > Everything about Debian's approach is in rabid opposition to this. This is not necessarily true. There are many Debian packages that can be installed in parallel. I still have gcc-2.95 installed and that hasn't been available in the Debian archive for years. It is named properly and doesn't conflict with any of the newer gccs. So it is possible to make parallel installs. > They want to scatter the files all over their precious FHS. This is true. And as a Debian user, I support them fully. I don't want to learn some stupid Ruby package directory convention. I already know if I install a Debian package that the configuration files go in /etc/packagename and the docs are in /usr/share/doc/packagename. Every package is like that and consistency is a good thing. I think the Debian Perl maintainers have gotten this right. They have a program "dh-make-perl" that will download a CPAN package and make it into a Debian package. This really gets you the best of both worlds. Hopefully something like that will get written for Python and Ruby (they haven't had their CPAN clones out for as long as CPAN, so give it time). > On top of all of that there's their release cycle where they freeze all the packages at a particular version number for several years for normal users. That's not just a Debian thing. %$#@! RHEL still ships a 2.6.18 kernel in their latest release! There is a certain class of people who are very, very conservative with their software upgrades. Debian Stable and RHEL appeal to those types. If you aren't one of those types, don't run them--instead run Debian Unstable or Fedora or Ubuntu. Those stay on the bleeding edge most of the time.
heresy 16y ago
Debian doesn't really work too well when you need multiple or new versions of software, or need something custom. It's either spend a week wrapping your head around all the different ways of getting something to spit out a conforming .deb, or falling back to something like RVM + RubyGems / PIP. The maintainer community is also reflexively defensive when they've broken something. The problem is never Debian breaking things into little unusable pieces, it's always upstream for not foreseeing how their software would be bastardized on Debian.
- davidw 16y ago
  > Debian doesn't really work too well when you need multiple or new versions of software, or need something custom. That's a fair complaint, and is also something of a complex issue, as there are tradeoffs between high quality integration, rapidly assimilating new stuff, the total number of packages in the repository, and so on. However, Zed's mistruths about the nature of Debian (which is a volunteer-drive non-profit organization, not a business), are not: "It is sadly pure business and has nothing to do with open source, quality, or culture." "I did not write it to boost the Debian business plan"
  - heresy 16y ago
    I think the story of "forking" system packages for local use needs improvement. And for all Debian's adherence to standards, it's unfortunate that one couldn't be agreed upon for source packages, 'apt-get source' is a mixed bag. This makes it a royal pain to maintain forks, because now you have to be up on three or four source packaging formats, in addition to getting the final binary format to comply with the standards. For the parts of the system where you don't care, using the distributor provided packages is fine. But when you do care, it is often simpler to just use pristine upstream rolled into your own deb as a starting point for managing package versions at your site.
    - blasdel 16y ago
      It's like the mainstream news media — anytime they report on a subject you know anything about, it's riddled with obvious errors. After this happens enough times, you know enough not to trust them about other subjects…
gaius 16y ago
Agreed 100%. He even says "the Debian business plan" - what plan is that!? Does Zed even know what Debian is? They aren't Red Hat!
FooBarWidget 16y ago
You are under the impression that Debian doesn't know about this problem or that they consider the current behavior to be a bug. Both are untrue. The current behavior is very much an explicit choice by Debian and no amount of bug reporting or patch submitting will change the situation.

grandalf 16y ago

Hypothetical question: Now that rvm has been created, would anyone still use apt-get to install ruby even if the latest version was supported? Sure you could argue that yes, ruby should be installed with apt-get and alternative versions should be handled with Debian's alternatives infrastructure... 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. 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. 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.

davidw 16y ago
> would anyone still use apt-get to install ruby even if the latest version was supported? Not everyone is a heavy Ruby user - someone might just want to install a package that depends on Ruby and be sure that things work. Just as they may want to install a package that depends on Java, Ada, Haskell, Erlang, Perl, Python, PHP, Ocaml, Tcl or any of the many other languages present in Debian, and not have to deal with a different package management system for each language on the computer. > Ruby and Python just happened to grow so quickly that their growth didn't immediately trigger the appropriate response from distro maintainers It's actually a fairly old problem. Perl and CPAN have many of the same issues. I'm not sure there's a perfect solution.
prodigal_erik 16y ago
apt-get or yum for ruby? Hell yes. After wasting countless hours on random versions of crap scattered around some servers' filesystems but not others, now nothing hits production without being in a package that installs and uninstalls cleanly and declares everything it relies on being present. That includes my own code, which we package ourselves.
- __david__ 16y ago

deleted 16y ago

[deleted]

poet 16y ago

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. That said, Zed is blowing this way out of proportion.

davidw 16y ago
> Just give your users a manual on how to install gems (or pip, or whatever) and let it be. Uh... that might work for one language, but for 10? 20? And some poor sysadmin is supposed to use all these disparate tools to install security fixes too? And you're forgetting that there are "end-user" programs that depend on those libraries as well, so they really do need to be packaged up. > That said, Zed is blowing this way out of proportion. That goes without saying.
- poet 16y ago
  And you're forgetting that there are "end-user" programs that depend on those libraries as well, so they really do need to be packaged up. I'm not forgetting this. I don't think the user's programs should use the same libraries (or even the same language install) that the distro's programs depend on. This way, if the user messed something up (like trying to upgrade a library), the entire distro wont be hosed. It's a really bad idea from a stability, security, and design standpoint if you don't keep these two things separate.

Corrado 16y ago

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. 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.

mycroftiv 16y ago

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?

blasdel 16y ago
The efforts of both Zed and Debian are based on the same corrupt motive: self-satisfaction As the upstream developer, Zed wants to make sure that his software is distributed in a manner that is useful to people and actually works and shit. This gives him jollies. As the distributors, the Debian contributors want to fullfil ideological goals, fit everything into their neat hierarchy, assuage neckbeard sysadmins that the version number is sufficiently ancient (not that the software is, given the distro patches), pretend to care about people running it on the PA-RISC port of Debian GNU/kFreeBSD, wank about licensing, and reach consensus. This gives self-important teenagers and manchildren all kinds of joillies.
- Mod_daniel 16y ago
  I can't believe this getting upvoted. I wonder how much software you use every single day thats created and maintained by "self-important teenagers and manchildren".

mgunes 16y ago

It might be worth re-evaluating this rant in the light of Lucas Nussbaum's (Debian Ruby maintainer) recent "mythbusting and FAQ" post: http://www.lucas-nussbaum.net/blog/?p=566 http://www.lucas-nussbaum.net/blog/?p=566

auxbuss 16y ago
This is far from being a rant. It's a concise exposition on the Debian/Ruby issues. Thanks for posting the link, but being labelled a rant, I nearly didn't go there. Just want to encourage others to read it for an excellent explanation of the issues at hand from the guy who is doing the work.
- telemachos 16y ago
  I'm pretty sure that "this rant" in the parent refers to Zed's post not Lucas's. The parent's point being "we should look at Zed's rant again after reading this discussion by a Debian Ruby maintainer."
  - mgunes 16y ago
    Exactly.

legooolas 16y ago

[Disclaimer: I'm not a Ruby developer, but have developed in plenty of languages, as well as being a sysadmin for a fair while] IME, separate package-management for each and every language is more painful than the problem he is describing. Rubygems, CPAN, whatever other languages use. 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. Edit: I thought that installing distro-supplied packages into /usr/local was against the FHS?

davidw 16y ago
> way to get the package-managers for language libraries and the distro to play together nicely and work for dependencies etc Yes, hacking the language's package manager to talk to the distribution package manager is probably the only way to really go about solving the problem in an elegant way, and even that is not without its pain points.
- legooolas 16y ago
  > pain points Absolutely, but this problem has been around for a long time, and fighting with distributions on how to get it to work won't help anyone. Of course, it also means that if you install a buggy version of a library from, say, CPAN then you could break distro-supplied packages... I guess it depends on which you value more: distributor-provided testing or being able to install out-of-band packages onto your distribution more easily and with proper dependencies.

pbiggar 16y ago

I think there is an important point here. Debian has a lot of control, and takes very little responsibility. A similar situation: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=380731 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=380731

protomyth 16y ago
wow, just wow. You would think that if you volunteer to maintain something, you would actually like what you are maintaining.

blasdel 16y ago

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 helping (see OpenSSL) The result is that any program or library that you use directly must be sourced from upstream, especially 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. 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). 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 debian-legal). 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.

ComputerGuru 16y ago

...and people ask me why I write tons of freeware, but make so little of it open source. 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. 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.

VMG 16y ago
You could still make it open source but craft the license in a way to prevent redistribution
- davidw 16y ago
  > You could still make it open source but craft the license in a way to prevent redistribution Then it would not be open source.
  - kleiba 16y ago
    Of course it would, but it would not be free software.
    - davidw 16y ago
      "open source" has a precise definition, and doesn't just mean "you get the source code": http://en.wikipedia.org/wiki/Open_Source_Definition http://en.wikipedia.org/wiki/Open_Source_Definition

thristian 16y ago

> 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. 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. 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.

aw3c2 16y ago
I read the first sentence, did not notice it was a quote and downvoted you. Sorry!
bad_user 16y ago
I used Debian on the desktop for 2 years (2008-2009) ... the whole time the Iceweasel package (their repackaged Firefox) has had its renderer broken, making some web pages unusable for me ... this wasn't a problem if I manually downloaded and installed Firefox, and it finally got fixed just before I switched to Ubuntu. It does have the best software repository ever, but boy how much it sucks when something's broken.
JoachimSchipper 16y ago
Third-party binaries suck, but you can compile from source, you know...

nakkiel 16y ago

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. 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.. 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. 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.

wazoox 16y ago

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. 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.

btilly 16y ago

Here is my beef with Debian. 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. Debian systematically strips those unit tests out, and never 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? 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? 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. 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.

__david__ 16y ago
I don't think it's so cut and dry. In the ideal case, the packages don't need tests because they are going into the system already tested. If the package is correct then running the unit tests is just redundant work because you are getting an identical copy of a package that already tested good with the appropriate dependencies. I think that's the theory anyway. On the other hand, theory does not always match reality. Debian CPAN packages do run the unit tests--they just run them when you create the package and not when you install the package. In fact, the package will not build unless the tests pass.
- btilly 16y ago
  Sorry, but it really is that cut and dry. In the ideal case you don't need unit tests. In the real world, they are useful. One of the big things that unit tests are supposed to catch are hidden dependencies. By nature, hidden dependencies are likely to be installed on the maintainer's machine, so unit tests only help if they are run somewhere else. As a prime example, the bug that Zed was complaining about was a dependency problem of EXACTLY this sort. It worked fine on the maintainer's machine. It didn't work on Zed's machine because he didn't have a key library installed. No unit test the maintainer can run would catch this. Even a stupid unit test Zed can run would have flagged this immediately. Incidentally about the Debian CPAN packages, my experience with them a few years back was that they were so consistently broken (usually because of locale issues) that I have a hard time believing that unit tests had actually been run by anyone. Or if they were, they were ignored.

xinuc 16y ago

I'm okay with Debian packages, unless someone include locusts as dependency http://xkcd.com/797/ http://xkcd.com/797/

whatajoke 16y ago

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?

blasdel 16y ago
Gentoo avoids making patches specific to itself wherever possible, when it does it's generally just to make it compile+work, the changes are straightforward, and they are applied live on your machine in a self-documenting way. The build process is also sophisticated enough to be able to 'slot' potentially-incompatible versions of the same package so that they can be installed simultaneously. From my recent snapshot of the package repo I can install 5 different simultaneous major versions of postgres, with a variety of independent build options.

mariana 16y ago

You know, maybe somebody would want to know the Debian POV on this issue: * http://www.lucas-nussbaum.net/blog/?p=566 http://www.lucas-nussbaum.net/blog/?p=566 * http://www.lucas-nussbaum.net/blog/?p=575 http://www.lucas-nussbaum.net/blog/?p=575 Debian is all about stability and volunteer effort. Whining is not going to fix things.