Recommended way to install Rubygems
in [Ruby]
|
From: Lucas Nussbaum on 18 Mar 2010 11:02 On 18/03/10 at 23:31 +0900, James Edward Gray II wrote: > On Mar 18, 2010, at 9:05 AM, Nick Brown wrote: > > > But just yesterday I was trying to install mechanize (via rubygems) > > on my 9.10 system, and it kept failing because 'net/https' was > > missing. And I was scratching my head wonder why the heck a core > > piece of ruby like that wouldn't be there... > > I completely agree that the split sucks. We run a Ruby service that > requires our users to install a simple script on their servers. It > does use net/https to communicate, so about 80% of our support issues > on Debian systems are us explaining to users how to finish their Ruby > install. > > In my opinion, the problem is that the Debian maintainers have changed > what it means to install Ruby. That's not OK to me, because it's not > their call to make. The Ruby core team gets to decide what it means > to install Ruby. Apparently, the ruby core team is OK with the current situation, since apt-get install ruby1.9.1-full/ruby-full is advertised on http://www.ruby-lang.org/en/downloads/. You might want to educate your users to read the documentation. Also, I disagree that it's not our call to make. Most of the software shipped by Debian is split in seperate packages, and Ruby is the only case where I hear people complaining about such a minor issue. (Also note that the split predates me being involved in Ruby maintenance.) > All of the standard libraries are meant to be > installed so you can count on having them. By changing that decision, > Debian has made it so you can't count on having them and that changes > the rules of what you can do with Ruby. If, maybe, the Ruby community fixed the fact that it's illegal to load all of stdlib in the same process (because of OpenSSL vs GPL), we could consider including ssl and readline in the default lib pkg. However, I don't see how we will make Ruby depend on installing Tcl/Tk (because of the TK bindings), or Emacs (because of the ruby mode for emacs). Note that even ruby-full doesn't install the TK and elisp stuff. -- | Lucas Nussbaum | lucas(a)lucas-nussbaum.net http://www.lucas-nussbaum.net/ | | jabber: lucas(a)nussbaum.fr GPG: 1024D/023B3F4F |
From: Lucas Nussbaum on 18 Mar 2010 11:15 On 18/03/10 at 23:45 +0900, Rick DeNatale wrote: > For example, we might need to run different versions of gems on the > same machine for different applications. We might run applications > using different versions of Rails, again for example. This is why > gems has the unpack command and why Rails allows gems to be vendored. > The base capability to have multiple versions of gems installed at the > same time is key. Gems which have been converted to (debian) packages > lose this ability, I think. > > We might need to run multiple versions of Ruby on the same system, > including 1.8.6, 1.8.7 and 1.9.x If the package maintainer views > 1.8.6 and 1.8.7 as the same 'version' this is problematical. > > Rubyists have developed solutions like ruby switcher and rvm to deal > with this requirement. Note there are not many development communities that are proud of the fact of having different, incompatible versions of the same software being widely used at the same time. Most other communities solve that by having more stable APIs and making sure that their important software supports the latest API. In Debian Squeeze (next Debian release), we ship (and support for several years) ruby 1.8 (likely 1.8.249+some backports) and ruby 1.9.1 (maybe a prerelease of 1.9.2, but unlikely). It would be totally insane, to, additionally, try to support several versions of the same libraries. Of course, if you want to install many different Ruby and gems versions, and then try to keep them in a sensible state wrt security issues (which are not that uncommon in the ruby world), that's your choice. > >> Also: don't let the unfriendly tone one often encounters on the internet > >> get ya down. The medium itself seems to encourage that sort of thing... > > > > That's not a reason to consider it acceptable. > > True enough, OTOH, I've found it a lot easier to live on the > inter-tubes if I develop a thick skin, and give everyone the benefit > of the doubt that they are not actively trying to be uncivil, even if > they express themselves in what I might perceive to be an uncivil > fashion. It's really to give the benefit of the doubt about civility to several people on this list. -- | Lucas Nussbaum | lucas(a)lucas-nussbaum.net http://www.lucas-nussbaum.net/ | | jabber: lucas(a)nussbaum.fr GPG: 1024D/023B3F4F |
From: James Edward Gray II on 18 Mar 2010 11:32 On Mar 18, 2010, at 10:02 AM, Lucas Nussbaum wrote: > On 18/03/10 at 23:31 +0900, James Edward Gray II wrote: >> On Mar 18, 2010, at 9:05 AM, Nick Brown wrote: >> >>> But just yesterday I was trying to install mechanize (via rubygems) >>> on my 9.10 system, and it kept failing because 'net/https' was >>> missing. And I was scratching my head wonder why the heck a core >>> piece of ruby like that wouldn't be there... >> >> I completely agree that the split sucks. We run a Ruby service that >> requires our users to install a simple script on their servers. It >> does use net/https to communicate, so about 80% of our support issues >> on Debian systems are us explaining to users how to finish their Ruby >> install. >> >> In my opinion, the problem is that the Debian maintainers have changed >> what it means to install Ruby. That's not OK to me, because it's not >> their call to make. The Ruby core team gets to decide what it means >> to install Ruby. > > Apparently, the ruby core team is OK with the current situation, since > apt-get install ruby1.9.1-full/ruby-full is advertised on > http://www.ruby-lang.org/en/downloads/. You might want to educate your > users to read the documentation. I added that to the site recently to help with this issue. ;) (It was recommended by another user running into the same problem, so I don't think I'm totally alone.) > Also, I disagree that it's not our call to make. Most of the software > shipped by Debian is split in seperate packages, and Ruby is the only > case where I hear people complaining about such a minor issue. I find you calling the legitimate complaint that some of us are trying to explain to you civilly, "such a minor issue," at least as offensive as those of our community who have been rude to you. I build Ruby software for a living and Debian's packaging does increase our support issues. Please respect that I have a viable opinion. >> All of the standard libraries are meant to be >> installed so you can count on having them. By changing that decision, >> Debian has made it so you can't count on having them and that changes >> the rules of what you can do with Ruby. > > If, maybe, the Ruby community fixed the fact that it's illegal to load > all of stdlib in the same process (because of OpenSSL vs GPL), we could > consider including ssl and readline in the default lib pkg. Ruby obviously ships these libraries together without issue. I assume it's because the responsibility falls to the user not to load them in some illegal situation. I don't see how that wouldn't be OK for Debian too. Obviously it is, since you do offer full install options, right? Or am I misunderstanding something? (Very possible, as I am not an expert in these matters.) James Edward Gray II
From: James Edward Gray II on 18 Mar 2010 11:35 On Mar 18, 2010, at 10:15 AM, Lucas Nussbaum wrote: > Note there are not many development communities that are proud of the > fact of having different, incompatible versions of the same software > being widely used at the same time. > > Most other communities solve that by having more stable APIs and making > sure that their important software supports the latest API. > Of course, if you want to install many different Ruby and gems versions, > and then try to keep them in a sensible state wrt security issues (which > are not that uncommon in the ruby world), that's your choice. You have lost the high ground in the civility argument. James Edward Gray II
From: Lucas Nussbaum on 18 Mar 2010 11:50
On 19/03/10 at 00:32 +0900, James Edward Gray II wrote: > On Mar 18, 2010, at 10:02 AM, Lucas Nussbaum wrote: > > > On 18/03/10 at 23:31 +0900, James Edward Gray II wrote: > >> On Mar 18, 2010, at 9:05 AM, Nick Brown wrote: > >> > >>> But just yesterday I was trying to install mechanize (via > >>> rubygems) on my 9.10 system, and it kept failing because > >>> 'net/https' was missing. And I was scratching my head wonder why > >>> the heck a core piece of ruby like that wouldn't be there... > >> > >> I completely agree that the split sucks. We run a Ruby service > >> that requires our users to install a simple script on their > >> servers. It does use net/https to communicate, so about 80% of our > >> support issues on Debian systems are us explaining to users how to > >> finish their Ruby install. > >> > >> In my opinion, the problem is that the Debian maintainers have > >> changed what it means to install Ruby. That's not OK to me, > >> because it's not their call to make. The Ruby core team gets to > >> decide what it means to install Ruby. > > > > Apparently, the ruby core team is OK with the current situation, > > since apt-get install ruby1.9.1-full/ruby-full is advertised on > > http://www.ruby-lang.org/en/downloads/. You might want to educate > > your users to read the documentation. > > I added that to the site recently to help with this issue. ;) (It > was recommended by another user running into the same problem, so I > don't think I'm totally alone.) > > > Also, I disagree that it's not our call to make. Most of the > > software shipped by Debian is split in seperate packages, and Ruby > > is the only case where I hear people complaining about such a minor > > issue. > > I find you calling the legitimate complaint that some of us are trying > to explain to you civilly, "such a minor issue," at least as offensive > as those of our community who have been rude to you. I build Ruby > software for a living and Debian's packaging does increase our support > issues. Please respect that I have a viable opinion. "Such a minor issue" was the split of many software packages into seperate Debian packages, not the split of Ruby. Sorry if I have offended you. Interestingly, we don't get many complaints on the Debian side about that. The only place where I hear about it is on this list. > >> All of the standard libraries are meant to be installed so you can > >> count on having them. By changing that decision, Debian has made > >> it so you can't count on having them and that changes the rules of > >> what you can do with Ruby. > > > > If, maybe, the Ruby community fixed the fact that it's illegal to > > load all of stdlib in the same process (because of OpenSSL vs GPL), > > we could consider including ssl and readline in the default lib pkg. > > Ruby obviously ships these libraries together without issue. I assume > it's because the responsibility falls to the user not to load them in > some illegal situation. > > I don't see how that wouldn't be OK for Debian too. Obviously it is, > since you do offer full install options, right? > > Or am I misunderstanding something? (Very possible, as I am not an > expert in these matters.) No, it just seems easier to ship everything in the same binary package if this doesn't add a dubious licensing situation (but IANAL). Also, the licensing issue will bite us (Debian) quite soon anyway. Currently, we ship Ruby linked to libreadline5 (which is GPLv2). It is likely that there will be a push to switch to libreadline6 (GPLv3), and that will put us in an interesting situation when Ruby will be the only application not having been switched to libreadline6. -- | Lucas Nussbaum | lucas(a)lucas-nussbaum.net http://www.lucas-nussbaum.net/ | | jabber: lucas(a)nussbaum.fr GPG: 1024D/023B3F4F | |