4 ms·

But then the tested binaries + libraries is a big directory which doesn't respect any of the unices way of organizing files. I don't see how this makes it any

by nkassis 16y ago

But then the tested binaries + libraries is a big directory which doesn't respect any of the unices way of organizing files. I don't see how this makes it any more convenient on the users than downloading it from upstream makes it. I compare this to things like installing nginx on ubuntu which comes with files in the places I expect (/etc instead of the configure script default of /usr/local/conf) etc. Packages are actually very convenient for 90% of what I user on my computer. Ruby and Clojure stuff are the only thing I download and install myself.

FooBarWidget 16y ago
Why does it matter whether it respects the way Unix organizes files? Other than having config files in /etc and having binaries in $PATH, who cares whether libfoo.so is in /usr/lib or in /usr/myawesomeapp.com/vendor/libraries?
- theBobMcCormick 16y ago
  Very true. The traditional Unix way of organizing files makes sense in a command line world, and I'd expect that sed, awk, grep and friends will continue to live in directories like /usr/bin. But for GUI desktop apps, there's really no good reason each app can't live in it's own directory.
  - rbanffy 16y ago
    Except that then you would have to do some contortions in order to use it or its parts from a command line or a script.
- sqrt17 16y ago
  Most commonly, it would be in /opt/awesomeapp/lib (and the binaries in /opt/awesomeapp/bin) See http://www.pathname.com/fhs/pub/fhs-2.3.html#OPTADDONAPPLICATIONSOFTWAREPACKAGES http://www.pathname.com/fhs/pub/fhs-2.3.html#OPTADDONAPPLICA... That's, more or less, what /opt is supposed to be. QT and KDE used to be "integrated" that way, until distros finally got around to put them into /usr. So, there really is a standardize mechanisms with those uncommunicative packages in the FHS. (Note that the Unix family as a whole does not standardize filesystem layout, even though Solaris also has /opt and uses it for exotic packages such as GNU gcc).
blasdel 16y ago
> Ruby and Clojure stuff are the only thing I download and install myself. And why do you do this? Because the Debian/Ubuntu packages for these things are old and broken, primarily because they are insistent on breaking up the packages and scattering the files all over the FHS they worship. They despise RubyGems because it installs packages in a self-contained way and lets you install multiple versions of everything without mangling the names. It puts them out of a job.
- rbanffy 16y ago
  > They despise RubyGems because it installs packages in a self-contained way A way that conflicts with the software management Linux distros use. You can't issue a command and have your system updated and, at the same time, your Ruby environment updated. Introducing some new gem can crash system software written in Ruby and make it impossible for the system management tools to rely on the same interpreter you do. If you want to install your gems, something like Python's virtualenv is recommended. I don't know if Ruby has one. If I relied on Ruby, I would make sure it had, even if it meant writing C.
- regularfry 16y ago
  Except it doesn't, because nobody (that I've ever heard of) backports security fixes to old gem versions.

by nkassis 16y ago

FooBarWidget 16y ago

Why does it matter whether it respects the way Unix organizes files? Other than having config files in /etc and having binaries in $PATH, who cares whether libfoo.so is in /usr/lib or in /usr/myawesomeapp.com/vendor/libraries?

theBobMcCormick 16y ago
Very true. The traditional Unix way of organizing files makes sense in a command line world, and I'd expect that sed, awk, grep and friends will continue to live in directories like /usr/bin. But for GUI desktop apps, there's really no good reason each app can't live in it's own directory.
- rbanffy 16y ago
  Except that then you would have to do some contortions in order to use it or its parts from a command line or a script.
sqrt17 16y ago
Most commonly, it would be in /opt/awesomeapp/lib (and the binaries in /opt/awesomeapp/bin) See http://www.pathname.com/fhs/pub/fhs-2.3.html#OPTADDONAPPLICATIONSOFTWAREPACKAGES http://www.pathname.com/fhs/pub/fhs-2.3.html#OPTADDONAPPLICA... That's, more or less, what /opt is supposed to be. QT and KDE used to be "integrated" that way, until distros finally got around to put them into /usr. So, there really is a standardize mechanisms with those uncommunicative packages in the FHS. (Note that the Unix family as a whole does not standardize filesystem layout, even though Solaris also has /opt and uses it for exotic packages such as GNU gcc).

blasdel 16y ago

> Ruby and Clojure stuff are the only thing I download and install myself. And why do you do this? Because the Debian/Ubuntu packages for these things are old and broken, primarily because they are insistent on breaking up the packages and scattering the files all over the FHS they worship. They despise RubyGems because it installs packages in a self-contained way and lets you install multiple versions of everything without mangling the names. It puts them out of a job.

rbanffy 16y ago
> They despise RubyGems because it installs packages in a self-contained way A way that conflicts with the software management Linux distros use. You can't issue a command and have your system updated and, at the same time, your Ruby environment updated. Introducing some new gem can crash system software written in Ruby and make it impossible for the system management tools to rely on the same interpreter you do. If you want to install your gems, something like Python's virtualenv is recommended. I don't know if Ruby has one. If I relied on Ruby, I would make sure it had, even if it meant writing C.
regularfry 16y ago
Except it doesn't, because nobody (that I've ever heard of) backports security fixes to old gem versions.