Looking over the Debian Ruby Policy. If you’re interested, a good
jumping point is here:
http://pkg-ruby-extras.alioth.debian.org/policy.html
According to the policy 3rd-party packages are installed directly into
/usr/lib/ruby/1.8/, right along side all the standard ruby files. I
realize that the Ruby distribution itself is split into multiple
packages for Debian, but it still seems like it would be better if
3rd-party packages where stored in their own space. When installing
packages manually they are placed in /usr/local/lib/site_ruby/1.8/, so
I would think a good place for 3rd-party Debian Ruby packages would be
in /usr/lib/site_ruby/1.8/.
In my particular usecase, being able to distinguish between what is
standard to Ruby from 3rd-party is helpful because I know that the
standard libs are all tied to the Ruby version (i.e they are all
“1.8”), whereas 3rd party libraries will have their own specific
versions. If I can’t distinguish between the two in the file system
then I am forced to pretend that each standard lib also has it’s own
specific version.
T.
On 25/06/06, [email protected] [email protected] wrote:
I
realize that the Ruby distribution itself is split into multiple
packages for Debian, but it still seems like it would be better if
3rd-party packages where stored in their own space.
In my experience, what ruby users want doesn’t cut much ice with
the debian packagers…
Dick D. wrote:
On 25/06/06, [email protected] [email protected] wrote:
I
realize that the Ruby distribution itself is split into multiple
packages for Debian, but it still seems like it would be better if
3rd-party packages where stored in their own space.
In my experience, what ruby users want doesn’t cut much ice with
the debian packagers…
I don’t really buy into that much. The ruby packagers are also ruby
users.
Still…
I’ve been a debian user for a very long time and for the last 3+ years
or so a Ruby user. In that much time I’ve firmly decided that it’s
easier for me to run Ruby from source than it is to try and use the ruby
packages.
This way everything lives in /usr/local and is structured like you would
expect it as a ruby user.
I don’t see anything changing my opinion on this any time soon.
Michael G. [email protected] writes:
I’ve been a debian user for a very long time and for the last 3+ years
or so a Ruby user. In that much time I’ve firmly decided that it’s
easier for me to run Ruby from source than it is to try and use the ruby
packages.
This way everything lives in /usr/local and is structured like you would
expect it as a ruby user.
Exactly the same here, except that that’s more or less grown
organically, since there were no Ruby packages back when I started. 
I do the same on OS X too—install from source, not DarwinPorts nor
the default (buggy) Ruby.
Michael G. wrote:
I don’t really buy into that much. The ruby packagers are also ruby
expect it as a ruby user.
I don’t see anything changing my opinion on this any time soon.
That’s exactly my point --the use of /usr/ and /usr/local/ shoud be
reflections of each other. I.e. Just as things are stored in /usr/local
when you handle it all manually, that’s how it should look in /usr when
handling it through apt-get.
BTW, Who actually is in charge of the Debian Ruby policies?
T.
On 6/25/06, Michael G. [email protected] wrote:
[snip] it’s
easier for me to run Ruby from source than it is to try and use the ruby
packages.
This way everything lives in /usr/local and is structured like you would
expect it as a ruby user. [snip]
Yup.
Actually, I like to install the whole enchilada into
–prefix=/opt/ruby-1.8.4. For one thing, it makes uninstalling Ruby as
easy as “rm -fr /opt/ruby-1.8.4” (note, Ruby does not currently come
with a “make uninstall”).
Anything else after that usually just gets installed via RubyGems.
—John
On Mon, Jun 26, 2006 at 12:47:47AM +0900, Michael G. wrote:
I don’t really buy into that much. The ruby packagers are also ruby
users.
Debian users who use aptitude to install ruby opt to let Debian handle
the installation, why do they care where all the files live as long as
it works? And if it doesn’t work, I complain via Debain Bug
Tracking. And I still can install gem and tradidtional gems in
addition.
Apt/dpkg can install many files of different packages into the same
directory because you can use apt, dpkg to find and deinstall these
files again, and this is the preferred way over just deleting
them. Don’t worry, let Debian handle it. It’s a feature.
If you are a control freak and really need to do your own ruby
install, noone prevents you from it even on Debian. I myself
contemplated this, but settled on apt + a few gems happily.
-Jürgen
2006/6/26, [email protected] [email protected]:
BTW, Who actually is in charge of the Debian Ruby policies?
People on Debian Mailing Lists -- Index for debian-ruby. Mail them.
Seo S.
On Fri, Jun 30, 2006 at 11:20:22PM +0900, [email protected] wrote:
directory because you can use apt, dpkg to find and deinstall these
it is one for programmed introspection. I have a script that searches
that ruby locatotins to know what libraries are present. I should be
able to distinguish bettween the ruby distribution (where everything is
tied to it’s version 1.8+ presently) and all others libs which have
their own versions. Debian’s ploicy of installing 3rd party ruby
packages directly in with the Ruby distibutition is therefore a poor
choice of design.
Again, usr/ and /usr/local should be reflections of one another.
T.
Who says that? Certainly not the FHS. On the contrary, the FHS is very
strict about /usr, but places few restrictions on /usr/local, and
specifically does not want to usurp the local administrator.
In short: /usr/local is for software different from your vendor’s.
On my system, debian manages /usr, but I manage /usr/local and it
certainly looks different, because sometimes I do things
differently. Ruby on Debian supports this beautifully by having
directories below /usr and /usr/local in its library search path.
The Debian maintainers don’t want to provide multiple versioned
libraries, because it is a support nightmare and doesn’t fit their
concept. I understand them. If you think your issue impacts the
functionality of ruby packages, file a bug report. But I feel the
maintainers will tell you that relying on a fixed file system layout
is a bad idea, and if your script relies on such it deserves to be non
portable. You might have to find other ways to query for installed
libraries.
-Jürgen
Juergen S. wrote:
functionality of ruby packages, file a bug report. But I feel the
maintainers will tell you that relying on a fixed file system layout
is a bad idea,
“fixed file system layout”? Ha! The whole FHS is a fixed file system
layout! But anyhow my only point is that the policy installs software
inside of other software. And that’s not really a good idea --even if
it manages to function. It ambiguates what belongs to what. I’ve
already posted the issue on the Debian with a couple of good responses,
agreeing that things aren;t quitre as they should be. In fact it was
also suggested that according to FHS they actaully belong in
/usr/share/ruby or, /usr/share/site_ruby, (ditto for /usr/local). That
strikes me as a bit odd. I always thought share/ was for data files.
But maybe so.
T.
Juergen S. wrote:
If you are a control freak and really need to do your own ruby
install, noone prevents you from it even on Debian. I myself
contemplated this, but settled on apt + a few gems happily.
Maybe I am misunderstood. Its not that it doesn’t function. Rather that
it mispreresents the ruby distributon --specifically it violates
versioning policies. So while it’s not a problem for requiring files,
it is one for programmed introspection. I have a script that searches
that ruby locatotins to know what libraries are present. I should be
able to distinguish bettween the ruby distribution (where everything is
tied to it’s version 1.8+ presently) and all others libs which have
their own versions. Debian’s ploicy of installing 3rd party ruby
packages directly in with the Ruby distibutition is therefore a poor
choice of design.
Again, usr/ and /usr/local should be reflections of one another.
T.
On Sun, Jul 02, 2006 at 03:58:51AM +0900, [email protected] wrote:
already posted the issue on the Debian with a couple of good responses,
agreeing that things aren;t quitre as they should be. In fact it was
also suggested that according to FHS they actaully belong in
/usr/share/ruby or, /usr/share/site_ruby, (ditto for /usr/local). That
strikes me as a bit odd. I always thought share/ was for data files.
But maybe so.
T.
share/ is for architecture independant files, lib/ is for architecture
dependant files. So ruby code belongs to share/ really, but
C-extensions would have to go to lib/. If they split those files
expect even more path weirdness 
The point of the FHS is, it specifies only some file and directory
locations to be relied on. Sadly, versioned ruby libraries were never
thought of when it was written.
As for ambiguation, dpkg does that one quite good, and you can query
it easily. All over the system stuff gets installed into common
directories like /etc, /bin, /lib, /usr/bin, etc., and it seems to work
really well.
-Jürgen