From: Austin Ziegler Date: 2007-10-29T12:54:00+09:00 Subject: Re: clarification of ruby libraries installation paths? On 10/28/07, Bob Proulx 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 * halostatue@gmail.com * http://www.halostatue.ca/ * austin@halostatue.ca * http://www.halostatue.ca/feed/ * austin@zieglers.ca