Hi, There's currently a big mess in the way Linux distros installs libraries. Debian, Fedora and openSUSE install the stlib to /usr/lib/ruby/1.8 For third-party libs provided as packages: - Debian installs to /usr/lib/ruby/1.8 as well, mixing them with the stdlib - Fedora installs to /usr/lib/ruby/site_ruby/1.8 - openSUSE uses the patch described in [ruby-core:10397] and installs to /usr/lib/ruby/vendor_ruby/1.8 For third-party libs installed manually by the local admin (e.g using setup.rb): - Debian installs to /usr/local/lib/site_ruby/1.8/ - Fedora installs to /usr/lib/ruby/site_ruby/1.8/ - openSUSE installs to /usr/lib/ruby/site_ruby/1.8/ , mixing with packaged libs It would be great if a standardized and sensible installation could be figured out for ruby1.9. Preferably, that would include installing manually installed libs somewhere under /usr/local, as /usr/lib is usually managed by the distribution's packaging system. (we should check what perl and python are doing about that) The same problem exists with gems: it would be great if packaged gems and locally installed gems were not mixed in the same dir.
on 22.10.2007 14:37
on 22.10.2007 17:14
On Mon, Oct 22, 2007, Lucas Nussbaum wrote: > [snip] > > It would be great if a standardized and sensible installation could be > figured out for ruby1.9. This is all *entirely* up to the packagers on those systems. They're the ones who have chosen to configure Ruby to install libraries in what I agree is a totally insane fashion. If you install Ruby from source on any of those platforms, you'll see sane behavior. It's the distro's problem, not Ruby's. Ben
on 22.10.2007 18:02
On 23/10/07 at 00:13 +0900, Ben Bleything wrote: > If you install Ruby from source on any of those platforms, you'll see > sane behavior. It's the distro's problem, not Ruby's. So, if everybody is insane expect the ruby developers, why don't they recommend a sensible behaviour that distros could follow?
on 22.10.2007 18:55
On 10/22/07, Lucas Nussbaum <lucas@lucas-nussbaum.net> wrote: > So, if everybody is insane expect the ruby developers, why don't they > recommend a sensible behaviour that distros could follow? They have. $PREFIX/bin $PREFIX/lib/ruby/$VERSION $PREFIX/lib/ruby/site_ruby/$VERSION $PREFIX/lib/ruby/gems/$VERSION -austin
on 22.10.2007 19:10
On 23/10/07 at 01:55 +0900, Austin Ziegler wrote: > > > sane behavior. It's the distro's problem, not Ruby's. > > So, if everybody is insane expect the ruby developers, why don't they > > recommend a sensible behaviour that distros could follow? > > They have. > > $PREFIX/bin > $PREFIX/lib/ruby/$VERSION > $PREFIX/lib/ruby/site_ruby/$VERSION > $PREFIX/lib/ruby/gems/$VERSION And how do you avoid clashes between third-party libs installed via apt/yum and third-party libs installed manually? Same with binaries: you have to install manually installed binaries (or binaries installed by gem) in /usr/local/bin: apt-get install rake ; gem install rake ; gem uninstall rake should restore apt's rake gem install rake ; apt-get install rake ; gem uninstall rake should keep apt's rake untouched
on 22.10.2007 19:24
On 10/22/07, Lucas Nussbaum <lucas@lucas-nussbaum.net> wrote: >>>> > And how do you avoid clashes between third-party libs installed via > apt/yum and third-party libs installed manually? Ruby doesn't care. Ruby shouldn't care. That's an issue for a distro to worry about. (Personally? I *never* use a distro Ruby because most of them don't know enough about Ruby to get it right.) > Same with binaries: you have to install manually installed binaries > (or binaries installed by gem) in /usr/local/bin: > > apt-get install rake ; gem install rake ; gem uninstall rake should > restore apt's rake > > gem install rake ; apt-get install rake ; gem uninstall rake should > keep apt's rake untouched RubyGems will overwrite the apt rake if it's installed in the same place that the Ruby libraries and binaries are installed (this was raised earlier this week; I think it's a probable bug, but I don't care since I never use a distro package, especially on Debian and derivatives). Apt may or may not touch the gem rake. Essentially, the *most* that Ruby and RubyGems should do is provide extra options. It isn't there to solve the problems that distro maintainers have made for themselves because they think that they know better. -austin
on 22.10.2007 20:33
Hi Austin, Would it be possible to have an answer from you on that topic without that very offensive tone? It's really tiring. On 23/10/07 at 02:24 +0900, Austin Ziegler wrote: > > > may or may not touch the gem rake. > > Essentially, the *most* that Ruby and RubyGems should do is provide > extra options. It isn't there to solve the problems that distro > maintainers have made for themselves because they think that they know > better. YOU don't care. Some people obviously care, because they care about the 1/3 of Debian users that installed the ruby debian package. The whole point here is not to be so selfish, and try to find a solution that makes our users' life easier. So let's try to be constructive.
on 22.10.2007 21:00
In article <20071022123642.GA19207@xanadu.blop.info>, Lucas Nussbaum <lucas@lucas-nussbaum.net> writes: > For third-party libs provided as packages: > For third-party libs installed manually by the local admin (e.g using > It would be great if a standardized and sensible installation could be > figured out for ruby1.9. I think it is easy to persuade matz because perl has vendor_perl directory.
on 22.10.2007 23:23
On 10/22/07, Lucas Nussbaum <lucas@lucas-nussbaum.net> wrote: > Would it be possible to have an answer from you on that topic without > that very offensive tone? It's really tiring. I suggest you read my posts without taking offence; I'm certainly not giving it. > On 23/10/07 at 02:24 +0900, Austin Ziegler wrote: > YOU don't care. Some people obviously care, because they care about the > 1/3 of Debian users that installed the ruby debian package. > The whole point here is not to be so selfish, and try to find a solution > that makes our users' life easier. So let's try to be constructive. Ruby doesn't exist to make a Debian maintainer's life easier. If Debian (or SUSE or RedHat or Solaris) maintainers don't want to use Ruby in the way that it configures itself (which is entirely sane), that's their choice. They (the maintainers) can ask for additional options (e.g., VENDOR_HOME has been suggested), but certainly shouldn't expect that Ruby maintainers will go out of their way to deal with their corner case issue. And it *is* a corner case issue, whether you want to admit it or not. -austin
on 23.10.2007 00:23
On Tue, Oct 23, 2007 at 01:55:29AM +0900, Austin Ziegler wrote: > > > sane behavior. It's the distro's problem, not Ruby's. $PREFIX defaults to /usr/local when you install ruby from source. Is it then "sane" for packagers to install to /usr/local/? > > So, if everybody is insane expect the ruby developers, why don't they > > recommend a sensible behaviour that distros could follow? > > They have. > > $PREFIX/bin > $PREFIX/lib/ruby/$VERSION > $PREFIX/lib/ruby/site_ruby/$VERSION Two directories, 3 classes of libraries: packaged libraries from ruby stlib packaged 3rd party libraries manually installed Which goes where? The various distros make different decisions here, in the absence of friendly guidance. > $PREFIX/lib/ruby/gems/$VERSION Two directories, 2 classes of libraries: packaged gems manually installed gems I guess they all go in one place? Btw, for those wondering why anybody would be so perverse as to not want to install using gem, here's something to think about. We build a debian-based network appliance. Manufacturing process involves auto-install and config of all packages (custom s/w and 3rd party) via net boot. We use the platform package format to take advantage of the auto install and configuration tools, not because we believe that any of the following commands are easier or harder to execute by a human: ruby setup.rb install gem install foo dpkg install foo yum install foo ... Of course, we don't install our appliances from the actual debian repository, we need better control than that, we do it from a locally maintained mirror. Even if we did install ruby libs using gems, we would need to setup a local gem repository. Luckily, debian has what we need so far for ruby, figuring out how to repackage gems hasn't been our problem. Cheers, Sam
on 23.10.2007 10:33
On 10/22/07, Sam Roberts <sroberts@uniserve.com> wrote: >>>> install Ruby from source on any of those platforms, you'll see sane >>>> behavior. It's the distro's problem, not Ruby's. > $PREFIX defaults to /usr/local when you install ruby from source. Is it > then "sane" for packagers to install to /usr/local/? ./configure --prefix /usr Please. $PREFIX *is* a configuration option. That's it. > > packaged libraries from ruby stlib > packaged 3rd party libraries > manually installed > > Which goes where? Ultimately, I don't care -- you'll never see class 2 on a system I install, because of poor packaging choices regarding Ruby with most of the distros. 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.) If we want a ./configure --vendor option (which really doesn't have much meaning for Ruby itself), ask for it. But that's *not* what was originally asked for; what was originally complained about was stuff that, frankly, Ruby doesn't have anything to do with and can't influence. > The various distros make different decisions here, in the absence of > friendly guidance. As well they should. >> $PREFIX/lib/ruby/gems/$VERSION > > Two directories, 2 classes of libraries: > > packaged gems > manually installed gems > > I guess they all go in one place? Seeing as, at least on Debian, there isn't the first class of gems, yes. Again: this is something to take up with the RubyGems folks, not on ruby-core. You won't get a lot of luck there -- that's been raised this past week and the answer has been "use GEM_PATH". > Btw, for those wondering why anybody would be so perverse as to not > want to install using gem, here's something to think about. I don't actually think that at all. I just don't think that it's Ruby's problem to solve, because *Ruby* doesn't have the three classes of libraries and two classes of Gems. The distros in question do. What will make it easier for you? A $VENDOR path? How will it work? What will it *actually* do for you that the existing system won't do? Where's the patch for discussion? Why is it being classified as a Ruby problem when it clearly *isn't* a general case problem? It doesn't apply to Solaris, AIX, HP-UX, Mac OS X, or Windows. It only applies to Linux distributions who claim special status. -austin
on 23.10.2007 10:34
On Tue, Oct 23, 2007 at 10:39:07AM +0900, Austin Ziegler wrote: > If we want a ./configure --vendor option (which really doesn't have much > meaning for Ruby itself), ask for it. But that's *not* what was > originally asked for; what was originally complained about was stuff > that, frankly, Ruby doesn't have anything to do with and can't > influence. To the world other than Austin: The original poster didn't "complain" about anything, he requested clarification on recommended practice. Ruby distributions might be more consistent if recomendations came from upstream, rather than cross-stream. > when it clearly *isn't* a general case problem? It doesn't apply to > Solaris, AIX, HP-UX, Mac OS X, or Windows. It only applies to Linux > distributions who claim special status. All the unix variants would benefit from advice-to-packagers. This is the first I've heard of --vendor (outside of akr's post). As far as I know, the ./configure has all the right options, packagers who don't know each other but do know about ruby need to have common guidance on using them. This isn't even a ruby-specific problem, lua has the same issues, and is slowly trying to get consistency among packagers. Its slow because its community is small, distros are slow to change, and mostly its users build the code themselves, but the dicussion is rant-free. Cheers, Sam
on 23.10.2007 22:15
Lucas Nussbaum wrote: > gem install rake ; apt-get install rake ; gem uninstall rake should keep > apt's rake untouched > To be honest, I'm somewhat with Austin here. There's two main ways you can see, say, apt-get and gem working together and within those two ways, several behaviors. a) The way you describe, where they are two separate entities that never overwrite each other. You can work like: 1) What you described. Each takes precedence over in the user's path based on what the user typed (what you described). Sounds lovely until you realize you will then end up quickly carrying around basically two full ruby trees. 2) apt-get takes precedence. installing a gem does nothing if there's an apt-get file for it. 3) gems always override apt-get in user's path. User must uninstall the gem first if he upgrades with apt-get to later version. b) Where they do overwrite each other. If I do apt-get install rake and then gem install rake, you could work like: 1) apt-get's rake is gone forever and I can never get it back unless I do apt-get install rake again, which would then override gem's stuff. If they are different versions, you may end up with some "junk" left behind of files the new (or old) version no longer needs. 2) gem has, say, apt-get .pkg knowledge, so that: apt-get uninstall rake then becomes the same as gem uninstall rake. Comments ======= a) sounds ideal, but I'm with Austin here. a.1) That road leads to madness. Been there, done that. Users get confused. Sysadmins get confused. Developers get confused. Two ruby trees, two gem trees, two site and local installs. Efficient, it ain't. a.2) Seems a very silly way to work. Package maintainers will like it, users probably won't. a.3) Probably the most sensible way to work with method a). Package maintainers will hate it thou. b) sound less ideal, but it is much more sane. b.1) Sucks, but it is very logical and people don't have that much issue learning about that behavior. Both package maintainers and users have the same problem. They CAN overwrite each other's stuff. Deal with it. b.2) Ideal, but good luck merging rpm, dpkg, etc. into gems! Really hard for gem developers to maintain. Madness also ensues, due to people's preferences and how each distro works. The big benefit of b.1) is that having junk files is not so terrible. Every two or three years you end up building a new system from scratch and can redist the stuff, forgetting about any junk files. And a good sysadmin should be able to write a cron job that queries gems and apt-get's dependencies to clean up the disk, say every 3 months. Is it a boring and delicate chore to do? Yes. But b.2 is pretty hard to manage, and a.1 is really well... wish you luck. P.S. I've dealt with similar issues at several large facilities, and b.1 always wins for being the least problematic and the one that trusts the user's brains. But if anyone pulls b.2 or a.1, it will be indeed a huge leap for mankind. Personally, I would prefer b.2 rather than a.1, but that's just me. -- Gonzalo Garramuñoggarra@advancedsl.com.ar AMD4400 - ASUS48N-E GeForce7300GT Kubuntu Edgy
on 24.10.2007 10:29
On 24/10/07 at 05:14 +0900, Gonzalo Garramuño wrote: >> gem install rake ; apt-get install rake ; gem uninstall rake should keep > (what you described). > 1) apt-get's rake is gone forever and I can never get it back unless > > a) sounds ideal, but I'm with Austin here. a.1) That road leads > to madness. Been there, done that. Users get confused. > Sysadmins get confused. Developers get confused. > Two ruby trees, two gem trees, two site and local > installs. Efficient, it ain't. > a.2) Seems a very silly way to work. Package maintainers will > like it, users probably won't. > a.3) Probably the most sensible way to work with method a). > Package maintainers will hate it thou. (a.3) seems like the only choice if going for (a). Furthermore, it's how it works currently with normal software. I if ./configure ; make ; make install $RANDOM_C_APP, it installs to /usr/local/bin, and takes precedence over what's in /usr/bin. The only thing that need to change in Ruby to make this possible is cleanup/standardization of its installation paths. > b) sound less ideal, but it is much more sane. > b.1) Sucks, but it is very logical and people don't have that > much issue learning about that behavior. > Both package maintainers and users have the same > problem. They CAN overwrite each other's stuff. > Deal with it. > b.2) Ideal, but good luck merging rpm, dpkg, etc. into gems! > Really hard for gem developers to maintain. > Madness also ensues, due to people's preferences and how > each distro works. no, of course, (b.2) is a nonsense. (b.1) looks very dangerous. It might silently or noisily break a lot of things, like checksuming tools that check that all files installed by packages are still identical to what's in the package. I'd personally favor (a.3) over (b.1). The problem is that (b.1) is the current ruby/gem behaviour, while (a.3) would require some minor changes.
on 25.10.2007 03:17
On 2007-10-22 21:36:44 +0900, Lucas Nussbaum wrote: > - openSUSE installs to /usr/lib/ruby/site_ruby/1.8/ , mixing with > packaged libs packaged libs go to: /usr/lib/ruby/vendor_ruby/1.8/
on 28.10.2007 20:37
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! > -- 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. 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. > 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. It would improve Ruby to bring consistency to the packaging and distribution of it. Bob
on 29.10.2007 04:54
On 10/28/07, Bob Proulx <bob@proulx.com> 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
on 29.10.2007 06:58
Austin Ziegler wrote: > 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".) There's a subtle distinction here between Perl, Python and Ruby. I don't think *any* current Linux distro will even *function* without Perl and Python. They are part of the base. You may not get all the development bells and whistles and libraries for Perl and Python, but you can edit and execute a Perl or Python script from the command line on any Linux system, and a fair amount of infrastructure in most distros uses one or the other. Not so for Ruby -- it's something you don't get by default, you have to ask for it. > 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. Well, in the case of Gentoo, it *is* a tarball install. :) Yet another reason I won't go back to Windows. :) Just remember: "If a program is useful, it will have to be maintained. If it is useless, it will have to be documented."
on 29.10.2007 17:57
On 29/10/07 at 12:54 +0900, Austin Ziegler wrote: > 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. Austin, please stop spreading FUD. > 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. And like a good citizen, you reported a bug about that, of course?
on 29.10.2007 21:30
On 10/29/07, Lucas Nussbaum <lucas@lucas-nussbaum.net> wrote: > Austin, please stop spreading FUD. It's not FUD if it's true. And what I said (about OpenSSL, etc.) certainly is -- or at least was as of the last time I actually looked at Debian directly and decided that people had to fix Debian's well-known and well-documented problems before I'd help them. > > 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. > And like a good citizen, you reported a bug about that, of course? Nope. I didn't have a Mac at that point, and I wasn't supporting Ruby on the Mac. I was supporting PDF::Writer on Ruby. It's not my responsibility to report bugs on your busted platform. The unbusted Ruby is the one from source. -austin
on 29.10.2007 22:35
Austin, On 29/10/07 at 12:54 +0900, Austin Ziegler wrote: > 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... ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Please provide an example (or better, a bug number) of what you mean by "didn't always state their dependencies clearly". It's true that some libs part of stdlib are not in the "libruby1.8" package, for good reasons. But their dependencies are clearly stated, AFAIK. > and then you'd have to redo some of them > because Debian (in its infinite zealotry) doesn't think that > OpenSSL is Free Enough Not true. If the ruby openssl lib is not installed by default when you install libruby1.8 (the stdlib package), it's because it would pull some other dependencies that are not needed if you don't use the openssl lib. So packages using the openssl lib will depend on it explicitely (or recommend it). See feed2imap, for which I'm the upstream dev, for an example. > and therefore doesn't install it by default and you can't do that > thing you could do out of the box on windows. True, there are some differences between Windows and Linux, and with the way you install apps on those two platforms. Some people prefer one platform, some people prefer the other. Both for good reasons, usually. > Or something like that. "something like that"? So you are clearly talking about things you don't understand, spreading FUD, as usual. How would you react if I said: - the PDF::Writer author, in its infinite zealotry, decided to do X in a non-standard compliant way, so you would have to redo X manually for each PDF you generate. - the PDF::Writer author is so insanely stupid that you'd better generate PDF by hand instead of using it. (none of the above being true -- I've never used PDF::Writer) Your answers on this thread are full of hate and anger. I'm sorry if you had a bad experience with Debian, Ubuntu, or something else in the past. I'm involved in Debian development, trying to improve things, but being received with so aggressive mails here make me reconsider a lot of things. Your behaviour clearly doesn't fit in the free software community. And I can't remember the last time I faced someone so annoying in the free software community. You don't care about how distros (or Apple) package ruby. I respect your POV. But I think that you made your opinion clear several times now, and that you should just refrain from replying to my mails, or to threads about distros, in the future. Several people encouraged my efforts (on-list and off-list) aiming at a better/more standardized ruby layout on distros, so there's clearly some interest in that, but your pollution of all threads on the subject with flames doesn't really allow productive discussions. Note that in those threads, I never asked anyone to "fix Debian's problem". As your said, what packagers choose to do is their responsibility. I'm seeking advices, trying to communicate with the upstream project to find good solutions. Usually, this is considered a Good Thing (at least by the other upstream devs I talk to). But your attitude is totally discouraging.
on 29.10.2007 23:05
On 10/29/07, Lucas Nussbaum <lucas@lucas-nussbaum.net> wrote: > > and therefore doesn't install it by default and you can't do that > > thing you could do out of the box on windows. > > True, there are some differences between Windows and Linux, and with the > way you install apps on those two platforms. Some people prefer one > platform, some people prefer the other. Both for good reasons, usually. > Please Lucas, don't take that as example. Out-of-the-box on Windows don't apply to OpenSSL either. Even if the ruby stblib has the extension pre-compiled for you, you still need OpenSSL installed to use it. So: non-identified dependencies still applies to Windows. > > Your answers on this thread are full of hate and anger. I'm sorry if you > had a bad experience with Debian, Ubuntu, or something else in the past. > I'm involved in Debian development, trying to improve things, but being > received with so aggressive mails here make me reconsider a lot of > things. > Again Lucas, please, don't take this "image" to represent all the users in this list, #irc or the Google Groups. I encourage you to keep the work you're doing in the Debian/Ubuntu front, since making life easy to lot of users is a daunting task and you should be rewarded :-) Also, discussions about packaging and "where to place things" help not just the distro you're working on, but also provide ideas to better managing of packages for Windows (as example) or enhance the platform (Ruby). Ruby isn't perfect, nor the programs / libraries created with. Even Ruby between version broke compatibility which requires matz, nobu or others patch it to keep it working. They are open to suggestions too, like us. > Your behaviour clearly doesn't fit in the free software community. And I > can't remember the last time I faced someone so annoying in the free > software community. > > You don't care about how distros (or Apple) package ruby. I respect your > POV. But I think that you made your opinion clear several times now, > and that you should just refrain from replying to my mails, or to > threads about distros, in the future. > If anyone don't provide a constructive solution, or at least something constructive to the thread, please, keep the rants in your draft folder... > Several people encouraged my efforts (on-list and off-list) aiming at a > better/more standardized ruby layout on distros, so there's clearly some > interest in that, but your pollution of all threads on the subject with > flames doesn't really allow productive discussions. > Again Lucas, keep working. As I said before, sometimes you need to fix code, sometimes you need to hack developers way of thinking. Is a hard task, but really worthy. Also, install some "anti-rant" filter and checking mails will be a bliss ;-) -- Luis Lavena Multimedia systems - Leaders are made, they are not born. They are made by hard effort, which is the price which all of us must pay to achieve any goal that is worthwhile. Vince Lombardi
on 29.10.2007 23:28
Lucas Nussbaum wrote: > On 24/10/07 at 05:14 +0900, Gonzalo Garramuño wrote: > (a.3) seems like the only choice if going for (a). Furthermore, it's how > it works currently with normal software. > I if ./configure ; make ; make install $RANDOM_C_APP, it installs to > /usr/local/bin, and takes precedence over what's in /usr/bin. > > The only thing that need to change in Ruby to make this possible is > cleanup/standardization of its installation paths. > Ah, okay. You want a.3. I thought you wanted a.1. So... what's wrong with the current paths? As far as I can tell, a.3) is how Ubuntu works right now. I'm not sure I understand what you see wrong with ruby's paths. You are supposed to have: $PREFIX/bin $PREFIX/lib/ruby/$RUBY_VERSION $PREFIX/lib/ruby/site_ruby/$RUBY_VERSION $PREFIX/lib/ruby/gems/$RUBY_VERSION Under Ubuntu, $PREFIX = /usr, which is indeed a tad confusing as it means you dump all your stuff in the common lib path. A distro should just be adding some symlinks from /usr/bin to $PREFIX/bin if needed and perhaps set RUBYLIB correctly and have RUBYOPT=-rubygems setup, so gems take priority. If you install from source in /usr/local, the distro will not know or is able to manage the package. -- Gonzalo Garramuñoggarra@advancedsl.com.ar AMD4400 - ASUS48N-E GeForce7300GT Kubuntu Edgy
on 29.10.2007 23:56
On 30/10/07 at 07:28 +0900, Gonzalo Garramuño wrote: > with the current paths? As far as I can tell, a.3) is how Ubuntu works > right now. I'm not sure I understand what you see wrong with ruby's paths. On the libraries front, I think that Debian's solution is "OK". We should just get the third-party libs out of /usr/lib/ruby/1.8 (in /usr/lib/ruby/vendor_ruby/1.8 like OpenSUSE) or somewhere else. On the Gems front, we currently don't package gems in Debian. But the right solution when we will, would then be to have two directories for gems: one in /usr/local/lib/ruby/gems/1.8 for locally installed gems, and one in /usr/lib/ruby/gems/1.8 for packaged gems. With the first one taking precedence over the first one. binaries from packaged gems would go to /usr/bin, while those from manually installed gems would go to /usr/local/bin. Does that sound sane? I still have to investigate how this is doable with the current rubygems code. Any help welcomed. :)
on 30.10.2007 00:36
Lucas Nussbaum wrote: > > Does that sound sane? > To be honest... no. Paths are okay, but... I really don't think I would find much benefit in having gems be available in apt-get. While apt-get's performance is certainly much better than rubygems and has better dependency information and tools available, apt-get currently holds a repository to absolutely *everything*. I know I would spend more time finding out a gem with apt-get than I currently do with "gem". I would also probably be forced to remember some prefix like: libruby-gem- or something, to distinguish, an equivalent library in perl or python. And it would probably difficult the task of listing all gems easily from the command-line. Another headache with apt-get is handling multiple versions. gems does this really beautifully, while apt-get is more oriented to have a single, latest version only setup. Finally, apt-get imo does not do building from source all that well and this is more or less a requirement for about 50% of the gems out there which may be delivered partially as .rb and a .so that has to be compiled. Also, unless apt-get reads and updates its repository often from the rubyforge website as gem does (besides apt-get's standard repos), it would quickly become out of date. Anyway, just my $0.02. -- Gonzalo Garramuñoggarra@advancedsl.com.ar AMD4400 - ASUS48N-E GeForce7300GT Kubuntu Edgy
on 30.10.2007 01:58
On Tue, 30 Oct 2007 08:35:29 +0900, Gonzalo Garramuño wrote: > I really don't think I would find much benefit in having gems be > available in apt-get. Agreed. I went through a really confusing experience a few months ago trying to help a novice get the current Ruby and Rails on his new Ubuntu laptop (I forget if it was Edgy or Feisty). There were packages for Rails, and there were gems for Rails, and it was hard to tell which he'd installed and what was failing and why. I ended up attempting to uninstall all the packages and install Ruby from source, but even -that- didn't work properly - something wasn't happy about zlib, even after downloading and installing zlib itself from source. I think I finally figured out that something about Ubuntu made the Ruby Makefile skip building zlib locally. Anyway, point is, it was very confusing, both for him and me, to have to distinguish between apt-get-installed gemlike things and actual gems. If you want to make gems visible through apt-get, do a simple wrapper package that does "gem install", but please don't duplicate (and thus fall behind) the gem repository!
on 30.10.2007 04:06
On 10/29/07, Lucas Nussbaum <lucas@lucas-nussbaum.net> wrote: > On the libraries front, I think that Debian's solution is "OK". We > should just get the third-party libs out of /usr/lib/ruby/1.8 (in > /usr/lib/ruby/vendor_ruby/1.8 like OpenSUSE) or somewhere else. There are no third-party libraries installed in /usr/lib/ruby/1.8. Those are in /usr/lib/ruby/site_ruby/1.8 for anyone using setup.rb. That's been this way as far as I can remember (and I've been using Ruby since 1.6). > I still have to investigate how this is doable with the current rubygems > code. Any help welcomed. :) You should ask on rubygems-devel for that. -austin
on 30.10.2007 04:26
On 10/29/07, Lucas Nussbaum <lucas@lucas-nussbaum.net> wrote: > On 29/10/07 at 12:54 +0900, Austin Ziegler wrote: > > 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... > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Please provide an example (or better, a bug number) of what you mean by > "didn't always state their dependencies clearly". It's true that some > libs part of stdlib are not in the "libruby1.8" package, for good > reasons. But their dependencies are clearly stated, AFAIK. I don't submit Debian bugs because I don't use Debian. I have, however, had to work with users who did use Debian and being a *good* software developer, I looked into their problems. I was royally pissed off at the results of what I found. > > and then you'd have to redo some of them > > because Debian (in its infinite zealotry) doesn't think that > > OpenSSL is Free Enough > Not true. If the ruby openssl lib is not installed by default when you > install libruby1.8 (the stdlib package), it's because it would pull some > other dependencies that are not needed if you don't use the openssl > lib. So packages using the openssl lib will depend on it explicitely (or > recommend it). See feed2imap, for which I'm the upstream dev, for an > example. Sorry, but libruby1.8 should include openssl as a dependency, because libruby-openssl (or whatever the hell it's called) is part of Ruby's stdlib. > > and therefore doesn't install it by default and you can't do that > > thing you could do out of the box on windows. > True, there are some differences between Windows and Linux, and with the > way you install apps on those two platforms. Some people prefer one > platform, some people prefer the other. Both for good reasons, usually. My point is that Debian delivers a broken Ruby. No more, no less. > > Or something like that. > "something like that"? So you are clearly talking about things you don't > understand, spreading FUD, as usual. I last dealt directly with Debian almost three years ago. If I can't remember the specifics, it's because I've been productive doing other things and not having to fix other peoples' problems with a broken Ruby distribution. > How would you react if I said: > - the PDF::Writer author, in its infinite zealotry, decided to > do X in a non-standard compliant way, so you would have to redo X > manually for each PDF you generate. If it was true -- as my comments about Debian's Ruby have been -- I wouldn't have a problem. Debian does not deliver a Ruby that's even remotely complete compared to a source-built Ruby. > - the PDF::Writer author is so insanely stupid that you'd better > generate PDF by hand instead of using it. > (none of the above being true -- I've never used PDF::Writer) If you want Unicode, that'd be true. > Your answers on this thread are full of hate and anger. I'm sorry if you > had a bad experience with Debian, Ubuntu, or something else in the past. > I'm involved in Debian development, trying to improve things, but being > received with so aggressive mails here make me reconsider a lot of > things. Well, I'm sorry for you. I have found nothing but obstructionism in the Debian community. > Your behaviour clearly doesn't fit in the free software community. And I > can't remember the last time I faced someone so annoying in the free > software community. Then you've been sheltered. I'm not actually hateful. I'm just not willing to let people request special behaviours because they're unwilling to change. Don't you even *recognise* that you're asking that Ruby bend to *your* distribution's nonsensical decisions? Isn't there the least bit of irony in what you've just asked? > You don't care about how distros (or Apple) package ruby. I respect your > POV. But I think that you made your opinion clear several times now, > and that you should just refrain from replying to my mails, or to > threads about distros, in the future. Then just make a decision. And stop breaking Ruby. > Several people encouraged my efforts (on-list and off-list) aiming at a > better/more standardized ruby layout on distros, so there's clearly some > interest in that, but your pollution of all threads on the subject with > flames doesn't really allow productive discussions. I haven't produce a single flame in this, Lucas. I just don't think that what you're asking for is worthwhile because it's trying to work around a decision that's, frankly, Not Ruby's Problem. I also advocate this position very strongly and don't just stand back like a wallflower. (You'll note that when Laurent posted his notes on about Apple's changes, I suggested that he talk to you guys and see what had been discussed on ruby-core -- so that a single solution based on Apple's decisions could be considered. There's a difference: Laurent and Apple provided a change that worked for them complete with diffs. It may be possible to work it into a standard solution that makes even the most difficult of distributions happy. But over the three years that I've seen this argued, I have *yet* to see a single diff provided by a Debian person on this.) > Note that in those threads, I never asked anyone to "fix Debian's > problem". As your said, what packagers choose to do is their > responsibility. I'm seeking advices, trying to communicate with the > upstream project to find good solutions. Usually, this is considered a > Good Thing (at least by the other upstream devs I talk to). But your > attitude is totally discouraging. (1) I'm not making a final decision. That belongs to Matz. If he decides that he wants to provide a way for you (the Linux distributions) to paint yourself out of the corner that you (the Linux distributions) have painted yourself into, then all is well and good. But, (2) I'm advocating the opposite position: there's no problem to fix here that Ruby needs to care about. This is a Linux distribution problem that needs to be fixed based on the philosophies of each Linux distribution. Note as well that: (3) RubyGems and/or setup.rb is the advocated way of distributing packages for Ruby. The former allows for things that most distro solutions don't allow (and that's a good thing) and the latter installs into site_ruby. None of which should be controversial. Also note *very carefully* that I have said that I think that RubyGems does certain things wrong when it comes to binary extensions. I don't have a solution for it, because it doesn't affect me right now -- but I think that it *is* wrong. I welcome your contributions. I think your request is worthless. Is that better? -austin
on 30.10.2007 04:34
On 10/29/07, Luis Lavena <luislavena@gmail.com> wrote: > still need OpenSSL installed to use it. > > So: non-identified dependencies still applies to Windows. OpenSSL is included in the Ruby One-Click Installer. OUT OF THE BOX, Ruby on Windows is more immediately useful than Ruby on Debian. By the way, I strongly suggest you look at the threads I've posted about the absolute *crap* that is the build situation on Windows and Microsoft's culpability on this nonsense. > > Your answers on this thread are full of hate and anger. I'm sorry if you > > had a bad experience with Debian, Ubuntu, or something else in the past. > > I'm involved in Debian development, trying to improve things, but being > > received with so aggressive mails here make me reconsider a lot of > > things. > Also, discussions about packaging and "where to place things" help not > just the distro you're working on, but also provide ideas to better > managing of packages for Windows (as example) or enhance the platform > (Ruby). Your suggestion (managing packages for Windows) indicates how little you know about the Windows situation overall. (The quality of the Ruby packages on Windows extends directly to Andy Hunt and Curt Hibbs tireless efforts at various times.) > They are open to suggestions too, like us. I'm open to suggestions, too. I didn't see a suggestion. I saw a request without a suggestion. I also think the request is nonsense. I said so. > folder... Please: read what I've written again. I've got *lots* of constructive suggestions in the thread in question. The first and foremost of which is to stop trying to shove Ruby into a Perl-shaped hole. If you want to have a distro-happy-making solution, provide one. Code talks. If I thought your problem was one worth solving, I'd look at providing a solution myself just to get the distro maintainers to stop asking for this crap (as they have been -- without providing patches -- for ~3 years, mostly with nonsense about how bad RubyGems is -- which is thankfully MISSING from Lucas's comments). I don't think it is. -austin
on 30.10.2007 04:44
On Oct 29, 6:55 pm, Lucas Nussbaum <lu...@lucas-nussbaum.net> wrote: > > > Ah, okay. You want a.3. I thought you wanted a.1. So... what's wrong > > with the current paths? As far as I can tell, a.3) is how Ubuntu works > > right now. I'm not sure I understand what you see wrong with ruby's paths. > > On the libraries front, I think that Debian's solution is "OK". We > should just get the third-party libs out of /usr/lib/ruby/1.8 (in > /usr/lib/ruby/vendor_ruby/1.8 like OpenSUSE) or somewhere else. Not quite sure I get this. Why isn't it just: Using distro package manager (apt-get, yum, etc): /usr/lib/ruby/1.8/ <- ruby core and standard /usr/lib/ruby/site_ruby/1.8/ <- 3rd party /usr/lib/ruby/gems/1.8/ <- "tunnelled" gems Using manual install methods (make, setup.rb, gem): /usr/local/lib/ruby/1.8/ <- ruby core and standard /usr/local/lib/ruby/site_ruby/1.8/ <- setup.rb /usr/local/lib/ruby/gems/1.8/ <- gem T.
on 30.10.2007 04:51
On 10/30/07, Austin Ziegler <halostatue@gmail.com> wrote: > absolute *crap* that is the build situation on Windows and Microsoft's > culpability on this nonsense. > Austin, you're the one that every post/thread I start asking for feedback you follow with a flamewar, or tell me that is not the right place to ask. All that followed by rants about microsoft and their tools or whatever crap is. You're the one that start pointing finger and didn't provide a solution, as you said: code talks... show me your code. > Your suggestion (managing packages for Windows) indicates how little > you know about the Windows situation overall. (The quality of the Ruby > packages on Windows extends directly to Andy Hunt and Curt Hibbs > tireless efforts at various times.) > No, it seems you're the one that have it off out sight. MSI installer are packages (actually a DB) with manifests that states where to put each file included into. Currently OCI is a big ZIP file with everything bundled, which is sub optimum and unmaintainable. *That* isn't the way of packaging this under Windows... I thought you knew that... Also, bundling OpenSSL with OCI don't make it "Out of the Box", but a hidden problem for someone trying to use Apache with manually installed OpenSSL with Ruby. Hey, since you rant so much about Windows, VC8, MinGW, x64 and all that, why you don't collaborate with Curt and Andy on One-Click-Installer? I'm doing something, what about you? Hmm... maybe your code can't talk after all? -- Luis Lavena Multimedia systems - Leaders are made, they are not born. They are made by hard effort, which is the price which all of us must pay to achieve any goal that is worthwhile. Vince Lombardi
on 30.10.2007 04:55
On Oct 22, 8:36 am, Lucas Nussbaum <lu...@lucas-nussbaum.net> wrote: > - openSUSE uses the patch described in [ruby-core:10397] and installs to > figured out for ruby1.9. Well, they could start by not breaking up the ruby standard library into a bunch of separate packages. I for one think this is a waste of effort. Matz decides what's "Ruby" and I think binary distributions of Ruby should respect his decisions here. Very little is gained by breaking it up, but much is had by keeping things together. T.
on 30.10.2007 05:08
Quoting transfire@gmail.com, on Tue, Oct 30, 2007 at 12:43:48PM +0900: > > On the libraries front, I think that Debian's solution is "OK". We > > should just get the third-party libs out of /usr/lib/ruby/1.8 (in > > /usr/lib/ruby/vendor_ruby/1.8 like OpenSUSE) or somewhere else. > > Not quite sure I get this. Why isn't it just: > > Using distro package manager (apt-get, yum, etc): > > /usr/lib/ruby/1.8/ <- ruby core and standard > /usr/lib/ruby/site_ruby/1.8/ <- 3rd party I think the above would be an example of Lucas' "somewhere else". Any suse users know what the thinking behind using vendor_ruby instead of site ruby is? > /usr/lib/ruby/gems/1.8/ <- "tunnelled" gems > > Using manual install methods (make, setup.rb, gem): > > /usr/local/lib/ruby/1.8/ <- ruby core and standard T, what would you see going in the above? Wouldn't all core be in /usr/lib/ruby/1.8? > /usr/local/lib/ruby/site_ruby/1.8/ <- setup.rb > /usr/local/lib/ruby/gems/1.8/ <- gem Seems reasonable to me, but there seem to be slight variants around the vendor/site (3rd party, but packaged by the distro). I think some systems don't put the /usr/local/.. into default paths, like Fedora. It would be nice if some of those packagers would get into this. Sam
on 30.10.2007 05:45
On Oct 30, 2007 12:06 AM, Sam Roberts <sroberts@uniserve.com> wrote: > > > /usr/lib/ruby/gems/1.8/ <- "tunnelled" gems > > > > Using manual install methods (make, setup.rb, gem): > > > > /usr/local/lib/ruby/1.8/ <- ruby core and standard > > T, what would you see going in the above? Wouldn't all core be in > /usr/lib/ruby/1.8? If you installed via a distro's package manager, yes. But if you install Ruby manually via make, I'd expect it in /usr/local. Isn't that what the local is intended for? > > /usr/local/lib/ruby/site_ruby/1.8/ <- setup.rb > > /usr/local/lib/ruby/gems/1.8/ <- gem > > Seems reasonable to me, but there seem to be slight variants around the > vendor/site (3rd party, but packaged by the distro). I think some > systems don't put the /usr/local/.. into default paths, like Fedora. It > would be nice if some of those packagers would get into this. I just see a simple division between distro controlled (/usr) and manual (/usr/local). If a system admin doesn't care about that division then ln -s /usr /usr/local And everything should still work fine. -- 7rans <transfire@gmail.com> BE HELP: http://manumission.info
on 30.10.2007 07:02
On 10/29/07, Trans <transfire@gmail.com> wrote: > > /usr/lib/ruby/vendor_ruby/1.8 > > Well, they could start by not breaking up the ruby standard library > into a bunch of separate packages. I for one think this is a waste of > effort. Matz decides what's "Ruby" and I think binary distributions of > Ruby should respect his decisions here. Very little is gained by > breaking it up, but much is had by keeping things together. The only exception that I'd really make would be Tk features because of X. But that's pretty much it. (Okay, I could also except OpenSSL as long as a parallel functionality were implemented as Apple seems to have done with Leopard's Ruby.) (The other set that annoys me is the separation of rdoc/ri/irb -- these aren't just programs, they're libraries we can reuse in our own codebase.) -austin
on 30.10.2007 14:00
Do we think that maybe, just maybe, things went off the rails when the discussion became no longer about Ruby but rather about "Austing Ziegler's Behavior)"? I'm presuming we're all adults. Could we start acting like it? Thanks. Looks like I will finally get a chance to use the 'm' for "mute" on Gmail. Best, Rick
on 30.10.2007 15:02
On 10/30/07, Rick Bradley <rick@rickbradley.com> wrote: > Do we think that maybe, just maybe, things went off the rails when the > discussion became no longer about Ruby but rather about "Austing > Ziegler's Behavior)"? > Rick and everyone on this list: please excuse my reaction. It seems that lately every constructive action (or desire to get understanding of the reasons) Ruby or RubyGems way of doing things (or inner workings) end with discussions like this. I just reacted on previous statements Austin made to rubygems-devel lists on this topic and prior discussion here about Ruby on Windows. If somehow this offend any egos, please take this as an apology. I tried a lot of times being constructive, helpful and polite, but sometimes the way some users reply to other's questions turn this into something nasty. If we start labelling every users choice of platform as "broken" and always tell they "your platform is broken, don't ask this here", similar reactions will show up. Again, all the ruby-core list members, please excuse this excessive off-topic. -- Luis Lavena Multimedia systems - Leaders are made, they are not born. They are made by hard effort, which is the price which all of us must pay to achieve any goal that is worthwhile. Vince Lombardi
on 30.10.2007 16:55
On 10/30/07, Luis Lavena <luislavena@gmail.com> wrote: > On 10/30/07, Rick Bradley <rick@rickbradley.com> wrote: > > Do we think that maybe, just maybe, things went off the rails when the > > discussion became no longer about Ruby but rather about "Austing > > Ziegler's Behavior)"? > > > > Rick and everyone on this list: please excuse my reaction. Yes, I agree with Rick, this has definitely gone off course. For the record, I want to state that Austin Ziegler has been always provided support for the One-Click Installer whenever I needed it and even continued to offer his time after Windows was no longer his primary platform. I would never doubt Austin's sincerity or commitment. Curt