[ruby] multilib and noarch

[David Lutterkort]

Ville Skyttä pointed out[1] that with the current packaging of ruby in
core, it's not possible to build noarch ruby packages right now, since
none of the directories on the standard ruby lib path ($:) are the same
on x86_64 and i386. 

The load path is made up of five dirs, all defined in the Config::CONFIG
hash in rbconfig: sitelibdir, sitearchdir, sitedir, rubylibdir, archdir.
With the current packaging, all these paths are underneath /usr/lib on
32bit platforms and under /usr/lib64 on 64bit platforms. The dirs with
'arch' in their name are meant for binary extensions (Ruby bindings),
and these dirs end in something that depends on the arch, i.e. Ruby
already makes sure that architecture-specific stuf gets installed into
architecture-specific dirs, no matter where ruby is installed.

I can see at least three ways to solve the noarch problem, i.e. ways to
provide a dir for noarch packages to install into that does not depend
on arch:
     1. Install sitelibdir, sitedir and rubylibdir always into /usr/lib,
        and the rest of ruby into %_libdir, depending on the platform.
        This is fairly dangerous because ruby largely assumes that it is
        installed into a single tree, and we would be the only ones
        splitting the ruby installation into two directory hierarchies.
     2. Add a dir to the default ruby load path,
        e.g. /usr/lib/ruby/VERSION/site_ruby/noarch, i.e. a path that
        does not change with the platform. Fairly simple, but requires
        that we do a similar dance for ruby gems, since there are both
        binary and noarch gems, and gems want to be installed into
        _their_ own directory tree, yet already manage the distinction
        between arches for binaries.
     3. Always install ruby into /usr/lib _except_ for the things that
        ld.so actually cares about (really only libruby). Since the
        stuff in /usr/lib/ruby is completely managed by ruby, and ruby
        has ways to distinguish between arches by itself, there is no
        need to rely on the distinction between /usr/lib and /usr/lib64

I would hugely prefer approach (3) since it seems the least intrusive in
terms of changing expectations of how a ruby installation is laid out;
noarch packages would install their code into sitelibdir.

David

[1]
https://www.redhat.com/archives/fedora-extras-list/2006-March/msg00079.html