Re: clarification of ruby libraries installation paths?

On 10/28/07, Bob Proulx <[e-mail]> wrote:
> Austin Ziegler wrote:
> > Sam Roberts wrote:
> > > Which goes where?
> > Ultimately, I don't care
> You are very very vocal about something that you do not care about!

I don't care what direction distro maintainers take when they're
making this decision. It's completely irrelevant to Ruby itself, and
it will ONLY have an impact on users of their systems. Although I like
Ubuntu, I will *never* install a package-based Ruby on a Debian system
because the packages for 1.6 and 1.8 were so badly mangled that you
had to install ten *different* packages that didn't always state their
dependencies clearly... and then you'd have to redo some of them
because Debian (in its infinite zealotry) doesn't think that OpenSSL
is Free Enough and therefore doesn't install it by default and you
can't do that thing you could do out of the box on windows. Or
something like that.

Or you get the Ruby on Tiger snafu: it was compiled as PPC with Intel
endianness, which meant that PDF::Writer and a handful of other
packages would never be able to work because String#unpack would never
work.

So, if packagers must do something *different* than a source install
of Ruby, then it's 100% their responsibility for making sure that they
choose something smart, making sure that it doesn't break things that
the user could upgrade themselves, and includes everything that's
actually needed to work (yes, Debian, rdoc is part of the Ruby
standard library, thankyouverymuch).

> > -- you'll never see class 2 on a system I install, because of poor
> > packaging choices regarding Ruby with most of the distros.
> Then it would be most productive to help the distros make better
> choices.

Install location is the least of their problems, and probably the only
one that they (generic they) are fully qualified to address.

> As things currently exist guidence is lacking and therefore everyone
> is forced to make independent decisions.  Without coordination these
> decisions will naturally have variance.  That is not as good for Ruby
> as if there were a policy that promoted consistency.

Install Ruby consistently then.

  ./configure
  make
  make test
  make install

If you must, use --prefix. Don't hack RubyGems to use /var/lib (!?!?).
If you want to have a graphics-UI-free version, disable Tk on build.
That's about the only thing you should separate from the standard
installation. If you *have* to split other things out, make sure you
really need to do so -- or make sure your dependencies are set
properly and tell people to stuff themselves. zlib is a *required*
dependency. OpenSSL or an equivalent is a *required* dependency (or at
least some API-compatible stuff for the digest code).

Developers create against the Ruby standard library. Your job, as a
distro maintainer, is to deliver a Ruby that provides that standard
library and the ability to extend Ruby in ways that are accepted in
the community. That includes RubyGems. You want to handle RubyGems
right? Package them *within* your packaging format. Sure, someone
might remove the .gem from the archive area, but that's not a huge
deal -- or it shouldn't be. Nothing says I can't do something like:

   apt-get install vim
   rm -rf /usr/local/share/vim

You know what? My Ubuntu system won't crash. I can run "apt-get
uninstall vim" and it'll bitch about the missing files (maybe), but it
won't crash.

(Added bonus: if you're packaging the .gem, you can actually package
your *own* .gem that contains a precompiled binary extension so you
don't have to worry about those.)

There are some things that I don't know that RubyGems handles well
(.so extensions aren't segregated by platform in any way, so far as I
can tell -- this is a hairy, but uncommon, problem).

> > On other systems, you'll never see class 3, because they don't use
> > anything BUT distro packages. (And that's what I'll use for things I
> > don't care about, like Python and Perl.)
> Hmm...  A hard core build-from-source Perl person would say the same.
> Building and installing Perl from first principles would be the only
> way for them for the same reasons you give for Ruby for yourself.  And
> the same for Python.  But I do not believe it is a good thing for the
> users of these projects.

Let me be very clear: I would act the same way toward Perl and Python
if OS-based package installs of them didn't behave correctly. (Where
correctly is "as if I had built Python from source".) I got to a point
with PDF::Writer where the first question was "what OS"? If the answer
was "Debian", I'd say "rebuild your Ruby from source. Debian doesn't
know how to package Ruby." I would not provide any further help before
they did that -- because the Debian packages were (and to some degree
still are) horribly broken compared to a source installation.

> It would improve Ruby to bring consistency to the packaging and
> distribution of it.

I don't agree. Leopard (Apple) has a different concept of packaging
and distribution than Debian, which is different than SUSE, which is
different than FreeBSD, etc. I don't have time to support all of those
different distributions. Neither, IMO, does any of the Ruby (including
JRuby, Rubinius, etc.) core developers. They support Ruby. Yes, build
issues are a Ruby problem. Installation beyond "./configure; make;
make install" really isn't.

There are such different philosophies represented here that I can't
see any way of providing such guidance beyond a "tell us a --vendor
path and we'll record it." So yeah, I don't care where you install it.
Just make sure that it's at least as good as the tarball install.

-austin
-- 
Austin Ziegler * [e-mail] * http://www.halostatue.ca/
               * [e-mail] * http://www.halostatue.ca/feed/
               * [e-mail]