7 ms·

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

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.
    - yourmomcalled 16y ago
      Excuse me, but I tried to direct you back to the original premise. Now it's an absurd claim? Did you read the article? It's not even my claim. And yes, if you read http://twitter.com/zedshaw http://twitter.com/zedshaw you will see that the bug I posted is one that Zed references. By the way, your "post" is quite the "epitome" of total "air quotery".
      - davidw 16y ago
        Yes, that "It's simply a tactic to make sure that you are stuck on Debian." was, and is, an absurd claim without a shred of support. He also says that "it is sadly pure business and has nothing to do with open source, quality, or culture." which is pretty odd, given that Debian is a non-profit, voluntary organization.
  - msy 16y ago
    I don't think it's anything to do with control and lockin, it's to do with the fact that Debian feel they have a far superior package management system and allowing other, inferior (from their perspective) systems is a Bad Idea which they'll fight tooth and nail every step of the way. It does seem silly from a rubyist's perspective but their approach does make a heck of a lot of complicated software work together in a way that makes administering complex server setups a doddle compared to how it could be. There's just a yawning philosophical gap between how the Debian and Ruby communities look at the world and approach software management.
    - legooolas 16y ago
      I'll bite: I'd say that it's more that if there's no (current) way to track what the other package management system is doing on the distro (any distro, not just Debian) then they can't tell what packages are installed and hence whether the distro-supplied packages can work with them...
    - cemerick 16y ago
      s/Ruby/Ruby, Perl, Java, Python If everyone thinks you're off in the wilderness, you might want to check yourself, maybe just a bit.
      - bryanlarsen 16y ago
        1. Perl isn't nearly as broken on Debian as Ruby is. Don't know about the others. 2. These packaging systems were all designed by and for developers. Debian was designed by and for system administrators. The fact that there are common problems is not surpising.
        cemerick 16y ago
        Fair enough re: #2. Given that, it's not at all surprising that the ruby and python folk have done rvm and pip (which, in a faux-spectrum, is a big shift towards what maven et al. provide in the java world). Of course, it's the debian maintainers' prerogative to structure things such that others generally pick up their toys and go play in their own sandboxes. I just get irritated when I hear people griping about it when it happens, as if system-level package managers have some kind of inherent priority.
- heresy 16y ago
  Why should the author report a bug when it's the incompetence of the Debian maintainer? The 'gem' command not working after installing the 'rubygems' package does seem like a bit of a bug, to put it mildly, you'd think a cursory test by the maintainer would catch that.
  - davidw 16y ago
    > Why should the author report a bug when it's the incompetence of the Debian maintainer? Because he cares about the bug being fixed, rather than just whining? The point is to focus on fixing the system, not on pointing fingers or telling eachother to fuck off. The maintainer most likely already had the ruby-ssl package, and so the 'cursory test' worked for him. Look, I don't think the rubygems package on Debian is a fantastic bit of work, but ultimately: It's free software. If you don't like it, either help fix it or don't use it. Point it out if you like, but don't be such a dick about it.
    - heresy 16y ago
      It's clear we disagree. The author put something out there under a free license, Debian benefits by including it in the distribution. There is no onus on the author whatsoever. People bitch because it's always Debian from which these problems originate. Mac OS X - Fine. FreeBSD - Fine. RedHat/CentOS - Fine. SuSE - Fine. Debian - Commands missing, functionality disabled, misconfigured.
      - davidw 16y ago
        The author put mongrel out there under a free license, as well as some unnamed gem, and various other things. The gem is not included in Debian. As to the "benefits" of Debian including anything, they certainly aren't pecuniary, but accrue mostly to the end users (or not, in this case). So, if you help Debian fix something, the beneficiaries are ultimately all the users of Debian, not really 'Debian' itself. > Mac OS X - Fine. FreeBSD - Fine. RedHat/CentOS - Fine. SuSE - Fine. Any sufficiently complex system, including every one of the above, has problems. They may differ from Debian's in type, nature and even quantity, but they exist. Including missing commands, disabled functionality, and misconfiguration.
- acabal 16y ago
  I don't use rubygems myself so I'm just commenting as a spectator. But I think it's very reasonable to ask that if someone (anyone) discovers a bug, then the right thing to do is to report it. They don't have to fix it themselves; maybe that responsibility falls on the rubygems package maintainer. But the maintainer will never know there's a bug until someone reports it. Yes, it does seem to be a critical and obvious-to-catch bug. But as davidw said, maybe the maintainer already had the prereqs installed, maybe they were having a bad day, and they just ran a quick test and saw that it worked and released it. Mistakes happen, and I'm sure the maintainer would be happy to fix those mistakes, but they can't be fixed if the maintainer doesn't even know about them. On a side note, I agree with Zed's rant on Debian being unique with its configuration and packaging layout. I use Ubuntu on my work laptop and so I've gotten used to the different filesystem layout for config files, etc. When it comes time to set up a server, am I going to go with a different distro and remember which distro has which config file in which location, or am I just going to stick with Ubuntu server because I already know it? I don't like having to make that choice.
- JoachimSchipper 16y ago
  Debian does have general policies and a culture. (Yes, we could say it's just a bunch of files on a bunch of FTP servers, but we can agree that that's stupid, right?) As to the bug report thing, let me clarify: why should upstream authors have to pay the support cost (in e.g. time and negative impressions of them) for bugs introduced by Debian's packagers?
  - davidw 16y ago
    > why should upstream authors have to pay the support cost (in e.g. time and negative impressions of them) for bugs introduced by Debian's packagers? They are just as capable of saying "that's a Debian bug, go file a bug report there". That's a small price to pay for being open source, in any case. Debian certainly picks up bugs that are intended for upstream, and there are certainly instances when Debian maintainers have been quite helpful with fixing them. And others where they haven't been. With that many people there are bound to be some really good ones, and some that are below average...
    - JoachimSchipper 16y ago
      "That's a Debian bug" is not useful - you can only determine that after you have analyzed the bug thoroughly, and gone to the length of getting out a Debian system instead of whatever you're usually developing on. But yes, some maintainers are very good and some are quite bad; however, Debian's policies and patch-happiness means that bad maintainers (can/tend to) do much more damage than in other distributions/OSes.
      - davidw 16y ago
        Well if you really want to play tough about it you just say that all bug reports for your software running on Debian must go through the package maintainer. You could even ignore them if you get a lot of bogus ones.
        JoachimSchipper 16y ago
        Yes, but even that is a half-solution - Debian users are still likely to think you suck and/or use alternatives, which means less users/prospective developers/testing.
- technomancy 16y ago
  The rubygems devs have asked nicely to get Debian to fix these issues, and have been turned down flatly.
  - cmsj 16y ago
    Have they offered to fix the underlying causes? E.g. Patch OpenSSL out for gnutls? Change the structure/metadata of gems so they are trivial to package? These are the likely prerequisites to a slick experience for their users on any distro
    - technomancy 16y ago
      > These are the likely prerequisites to a slick experience for their users on any distro You'd think, but apparently that's not the case, as Debian is the only distributor who breaks rubygems when packaging it.
CrLf 16y ago
This because upstream projects usually can't be bothered to do integration work, and it's up to the distributions to do it and that means patches (which are normally separated from the upstream tarball in the source packages). Debian adds patches, but so does Red Hat/Fedora. Since these are the two main distributions (maybe not by themselves, but because they form the base for most others), then you criticism can be applied to 99% of the distributions out there. And bug reports about integration work should go to the distribution, and not upstream developers.
- JoachimSchipper 16y ago
  Look, I understand that combining gcc/binutils/glibc is a complete clusterfuck that needs some patches (each of these projects is "individually" at least somewhat sane, but they don't like working together at all), and I understand that there is a lot of shitty code in the average desktop environment. Really, some patches probably are necessary. (Although there's a whole debate about feeding them upstream that you could have at this point.) But why does Debian split up Postfix (well-written, actively maintained) into a zillion different packages stitched together by dynamic loading, instead of just configuring it properly? Why does Debian fuck up OpenSSL?
  - mariana 16y ago
    Disclaimer: Debian Maintainer here. If you need plain old Postfix, you just aptitude install postfix. If you need LDAP support in your Postfix instance, you just aptitude install postfix-ldap. Is it really that hard? And regarding OpenSSL, the problem is not in Debian. Just check http://people.gnome.org/~markmc/openssl-and-the-gpl.html http://people.gnome.org/~markmc/openssl-and-the-gpl.html OpenSSL always had a problematic license.
    - JoachimSchipper 16y ago
      No, it's not hard at all - I don't think it took me more than one minute to figure out. It is, however, an example of a gratuitous change. With respect to the OpenSSL stuff, I'm not talking about the GPL license - I'm talking about http://www.debian.org/security/2008/dsa-1571 http://www.debian.org/security/2008/dsa-1571, one of the most painful security issues in recent memory and caused by a meddling maintainer. (Certainly, the upstream team could have more clearly warned him, but without the maintainers changes everything would have worked just fine.) I understand you spend a lot of your free time working for free, and I appreciate your good intentions and the good that Debian and Debian's developers have done (e.g. writing lots of man pages for programs that have none) - but I do think Debian has some really questionable sides as well.
__david__ 16y ago
> Also: why should software authors have to write bug reports to Debian? What is the alternative? Should software authors be given carte blanche control of their own packages, regardless of their knowledge and commitment to the Debian platform and ideals? The goal is to make a working system, not to indulge every author that thinks their package is the exception to the guidelines laid out by the Debian members. I have to say, I just installed Debian's postgresql-9.0 package and I was pleasantly surprised. They've packaged things in such a way that you can install 9.0 and 8.4 in parallel. Yes, it is different than the default postgres install. Instead of everything being in one directory they put config files in /etc, library files in /usr/lib and your db in /var/lib--just like every other package on the system. This seems like the right kind of packaging to me--it makes the system consistent. Of course, for every good package like postgres there's a package with some epically stupid decision (netcat-traditional's "-q" patch).
- JoachimSchipper 16y ago
  > What is the alternative? If Debian made it a policy to change packages as little as possible (which is not "not at all"), these problems wouldn't show up. Also, yes, your shiny PostgreSQL package now matches every other Debian package, but it is different from every non-Debian PostgreSQL install out there. Zed wasn't talking about lock-in for nothing.
  - davidw 16y ago
    > If Debian made it a policy to change packages as little as possible (which is not "not at all"), these problems wouldn't show up. No, but others would show up. Come on, these things are engineering tradeoffs, with both positive and negative aspects. Even where we disagree about the benefits and disadvantages, we should agree to disagree in a civil way, rather than calling for "in-person confrontations". There are certainly technical complaints to be made about Debian (I could make a long list myself), but Zed's attitude is way out of line.
    - nailer 16y ago
      Agreed. Specifically allowing non-standard locations to remain in packages would cause the FHS would be broken, this would mean: - config files would be shoved all over the place, without being able to back up /etc as a config location or map frequently read data to var - You couldn't partition your disks reaosnably beyond a single filesystem as there's no way to predict where apps will shove their junk - Uninstalling apps would leave junk cron jobs and other files made manually rather than put into include dirs - Your PATH would be exceedingly long - You'd end up using 'find' a lot more to know where a particular library is.

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.
  - yourmomcalled 16y ago
    Excuse me, but I tried to direct you back to the original premise. Now it's an absurd claim? Did you read the article? It's not even my claim. And yes, if you read http://twitter.com/zedshaw http://twitter.com/zedshaw you will see that the bug I posted is one that Zed references. By the way, your "post" is quite the "epitome" of total "air quotery".
    - davidw 16y ago
      Yes, that "It's simply a tactic to make sure that you are stuck on Debian." was, and is, an absurd claim without a shred of support. He also says that "it is sadly pure business and has nothing to do with open source, quality, or culture." which is pretty odd, given that Debian is a non-profit, voluntary organization.
- msy 16y ago
  I don't think it's anything to do with control and lockin, it's to do with the fact that Debian feel they have a far superior package management system and allowing other, inferior (from their perspective) systems is a Bad Idea which they'll fight tooth and nail every step of the way. It does seem silly from a rubyist's perspective but their approach does make a heck of a lot of complicated software work together in a way that makes administering complex server setups a doddle compared to how it could be. There's just a yawning philosophical gap between how the Debian and Ruby communities look at the world and approach software management.
  - legooolas 16y ago
    I'll bite: I'd say that it's more that if there's no (current) way to track what the other package management system is doing on the distro (any distro, not just Debian) then they can't tell what packages are installed and hence whether the distro-supplied packages can work with them...
  - cemerick 16y ago
    s/Ruby/Ruby, Perl, Java, Python If everyone thinks you're off in the wilderness, you might want to check yourself, maybe just a bit.
    - bryanlarsen 16y ago
      1. Perl isn't nearly as broken on Debian as Ruby is. Don't know about the others. 2. These packaging systems were all designed by and for developers. Debian was designed by and for system administrators. The fact that there are common problems is not surpising.
      - cemerick 16y ago
        Fair enough re: #2. Given that, it's not at all surprising that the ruby and python folk have done rvm and pip (which, in a faux-spectrum, is a big shift towards what maven et al. provide in the java world). Of course, it's the debian maintainers' prerogative to structure things such that others generally pick up their toys and go play in their own sandboxes. I just get irritated when I hear people griping about it when it happens, as if system-level package managers have some kind of inherent priority.
heresy 16y ago
Why should the author report a bug when it's the incompetence of the Debian maintainer? The 'gem' command not working after installing the 'rubygems' package does seem like a bit of a bug, to put it mildly, you'd think a cursory test by the maintainer would catch that.
- davidw 16y ago
  > Why should the author report a bug when it's the incompetence of the Debian maintainer? Because he cares about the bug being fixed, rather than just whining? The point is to focus on fixing the system, not on pointing fingers or telling eachother to fuck off. The maintainer most likely already had the ruby-ssl package, and so the 'cursory test' worked for him. Look, I don't think the rubygems package on Debian is a fantastic bit of work, but ultimately: It's free software. If you don't like it, either help fix it or don't use it. Point it out if you like, but don't be such a dick about it.
  - heresy 16y ago
    It's clear we disagree. The author put something out there under a free license, Debian benefits by including it in the distribution. There is no onus on the author whatsoever. People bitch because it's always Debian from which these problems originate. Mac OS X - Fine. FreeBSD - Fine. RedHat/CentOS - Fine. SuSE - Fine. Debian - Commands missing, functionality disabled, misconfigured.
    - davidw 16y ago
      The author put mongrel out there under a free license, as well as some unnamed gem, and various other things. The gem is not included in Debian. As to the "benefits" of Debian including anything, they certainly aren't pecuniary, but accrue mostly to the end users (or not, in this case). So, if you help Debian fix something, the beneficiaries are ultimately all the users of Debian, not really 'Debian' itself. > Mac OS X - Fine. FreeBSD - Fine. RedHat/CentOS - Fine. SuSE - Fine. Any sufficiently complex system, including every one of the above, has problems. They may differ from Debian's in type, nature and even quantity, but they exist. Including missing commands, disabled functionality, and misconfiguration.
acabal 16y ago
I don't use rubygems myself so I'm just commenting as a spectator. But I think it's very reasonable to ask that if someone (anyone) discovers a bug, then the right thing to do is to report it. They don't have to fix it themselves; maybe that responsibility falls on the rubygems package maintainer. But the maintainer will never know there's a bug until someone reports it. Yes, it does seem to be a critical and obvious-to-catch bug. But as davidw said, maybe the maintainer already had the prereqs installed, maybe they were having a bad day, and they just ran a quick test and saw that it worked and released it. Mistakes happen, and I'm sure the maintainer would be happy to fix those mistakes, but they can't be fixed if the maintainer doesn't even know about them. On a side note, I agree with Zed's rant on Debian being unique with its configuration and packaging layout. I use Ubuntu on my work laptop and so I've gotten used to the different filesystem layout for config files, etc. When it comes time to set up a server, am I going to go with a different distro and remember which distro has which config file in which location, or am I just going to stick with Ubuntu server because I already know it? I don't like having to make that choice.
JoachimSchipper 16y ago
Debian does have general policies and a culture. (Yes, we could say it's just a bunch of files on a bunch of FTP servers, but we can agree that that's stupid, right?) As to the bug report thing, let me clarify: why should upstream authors have to pay the support cost (in e.g. time and negative impressions of them) for bugs introduced by Debian's packagers?
- davidw 16y ago
  > why should upstream authors have to pay the support cost (in e.g. time and negative impressions of them) for bugs introduced by Debian's packagers? They are just as capable of saying "that's a Debian bug, go file a bug report there". That's a small price to pay for being open source, in any case. Debian certainly picks up bugs that are intended for upstream, and there are certainly instances when Debian maintainers have been quite helpful with fixing them. And others where they haven't been. With that many people there are bound to be some really good ones, and some that are below average...
  - JoachimSchipper 16y ago
    "That's a Debian bug" is not useful - you can only determine that after you have analyzed the bug thoroughly, and gone to the length of getting out a Debian system instead of whatever you're usually developing on. But yes, some maintainers are very good and some are quite bad; however, Debian's policies and patch-happiness means that bad maintainers (can/tend to) do much more damage than in other distributions/OSes.
    - davidw 16y ago
      Well if you really want to play tough about it you just say that all bug reports for your software running on Debian must go through the package maintainer. You could even ignore them if you get a lot of bogus ones.
      - JoachimSchipper 16y ago
        Yes, but even that is a half-solution - Debian users are still likely to think you suck and/or use alternatives, which means less users/prospective developers/testing.
technomancy 16y ago
The rubygems devs have asked nicely to get Debian to fix these issues, and have been turned down flatly.
- cmsj 16y ago
  Have they offered to fix the underlying causes? E.g. Patch OpenSSL out for gnutls? Change the structure/metadata of gems so they are trivial to package? These are the likely prerequisites to a slick experience for their users on any distro
  - technomancy 16y ago
    > These are the likely prerequisites to a slick experience for their users on any distro You'd think, but apparently that's not the case, as Debian is the only distributor who breaks rubygems when packaging it.

CrLf 16y ago

This because upstream projects usually can't be bothered to do integration work, and it's up to the distributions to do it and that means patches (which are normally separated from the upstream tarball in the source packages). Debian adds patches, but so does Red Hat/Fedora. Since these are the two main distributions (maybe not by themselves, but because they form the base for most others), then you criticism can be applied to 99% of the distributions out there. And bug reports about integration work should go to the distribution, and not upstream developers.

JoachimSchipper 16y ago
Look, I understand that combining gcc/binutils/glibc is a complete clusterfuck that needs some patches (each of these projects is "individually" at least somewhat sane, but they don't like working together at all), and I understand that there is a lot of shitty code in the average desktop environment. Really, some patches probably are necessary. (Although there's a whole debate about feeding them upstream that you could have at this point.) But why does Debian split up Postfix (well-written, actively maintained) into a zillion different packages stitched together by dynamic loading, instead of just configuring it properly? Why does Debian fuck up OpenSSL?
- mariana 16y ago
  Disclaimer: Debian Maintainer here. If you need plain old Postfix, you just aptitude install postfix. If you need LDAP support in your Postfix instance, you just aptitude install postfix-ldap. Is it really that hard? And regarding OpenSSL, the problem is not in Debian. Just check http://people.gnome.org/~markmc/openssl-and-the-gpl.html http://people.gnome.org/~markmc/openssl-and-the-gpl.html OpenSSL always had a problematic license.
  - JoachimSchipper 16y ago
    No, it's not hard at all - I don't think it took me more than one minute to figure out. It is, however, an example of a gratuitous change. With respect to the OpenSSL stuff, I'm not talking about the GPL license - I'm talking about http://www.debian.org/security/2008/dsa-1571 http://www.debian.org/security/2008/dsa-1571, one of the most painful security issues in recent memory and caused by a meddling maintainer. (Certainly, the upstream team could have more clearly warned him, but without the maintainers changes everything would have worked just fine.) I understand you spend a lot of your free time working for free, and I appreciate your good intentions and the good that Debian and Debian's developers have done (e.g. writing lots of man pages for programs that have none) - but I do think Debian has some really questionable sides as well.

__david__ 16y ago

> Also: why should software authors have to write bug reports to Debian? What is the alternative? Should software authors be given carte blanche control of their own packages, regardless of their knowledge and commitment to the Debian platform and ideals? The goal is to make a working system, not to indulge every author that thinks their package is the exception to the guidelines laid out by the Debian members. I have to say, I just installed Debian's postgresql-9.0 package and I was pleasantly surprised. They've packaged things in such a way that you can install 9.0 and 8.4 in parallel. Yes, it is different than the default postgres install. Instead of everything being in one directory they put config files in /etc, library files in /usr/lib and your db in /var/lib--just like every other package on the system. This seems like the right kind of packaging to me--it makes the system consistent. Of course, for every good package like postgres there's a package with some epically stupid decision (netcat-traditional's "-q" patch).

JoachimSchipper 16y ago
> What is the alternative? If Debian made it a policy to change packages as little as possible (which is not "not at all"), these problems wouldn't show up. Also, yes, your shiny PostgreSQL package now matches every other Debian package, but it is different from every non-Debian PostgreSQL install out there. Zed wasn't talking about lock-in for nothing.
- davidw 16y ago
  > If Debian made it a policy to change packages as little as possible (which is not "not at all"), these problems wouldn't show up. No, but others would show up. Come on, these things are engineering tradeoffs, with both positive and negative aspects. Even where we disagree about the benefits and disadvantages, we should agree to disagree in a civil way, rather than calling for "in-person confrontations". There are certainly technical complaints to be made about Debian (I could make a long list myself), but Zed's attitude is way out of line.
  - nailer 16y ago
    Agreed. Specifically allowing non-standard locations to remain in packages would cause the FHS would be broken, this would mean: - config files would be shoved all over the place, without being able to back up /etc as a config location or map frequently read data to var - You couldn't partition your disks reaosnably beyond a single filesystem as there's no way to predict where apps will shove their junk - Uninstalling apps would leave junk cron jobs and other files made manually rather than put into include dirs - Your PATH would be exceedingly long - You'd end up using 'find' a lot more to know where a particular library is.