Recommended way to install Rubygems
in [Ruby]
|
From: Austin Ziegler on 18 Mar 2010 10:31 On Thu, Mar 18, 2010 at 10:21 AM, Lucas Nussbaum <lucas(a)lucas-nussbaum.net> wrote: > OpenSSL doesn't have a lot of fans, because of its licence that prevents > it from being linked to GPL software. Yes, it could be possible to ship > openssl.so and readline.so in the same package, but then it would be > harder to argue that Debian does enough to protect the linking of > readline (GPLv2) with openssl. The situation would be much simpler if > Ruby switched to GNU TLS, for example. Your first sentence is incorrect; OpenSSL is both better known and more widely used in the real world than GNU TLS is likely to ever be. GNU TLS is preferred by people who have subscribed to the GNU philosophy, which doesn't include everyone in the Ruby world, and those of us who prefer OpenSSL see GNU TLS as a zany outlier created by people who have nothing better to do with their time than to worry about the attribution clause (I believe that's the part that makes GNU software incompatible with OpenSSL licensing, since GNU believes that attribution isn't necessary). That said, if someone were to make an SSL/TLS layer for Ruby that could reasonably replace the OpenSSL namespace and that both "require 'openssl'" and "require 'gnutls'" would satisfy, then I think we'd see traction. Since this is apparently a problem for people who prefer GNU TLS, I suggest that it is in their interest to do so. -austin -- Austin Ziegler halostatue(a)gmail.com austin(a)halostatue.ca http://www.halostatue.ca/ http://twitter.com/halostatue
From: James Edward Gray II on 18 Mar 2010 10:31 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. 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. > The easiest way to solve this problem would be to rename "ruby" to > "ruby-core" or something, then rename "ruby-full" to "ruby". This would > allow the few who want partial ruby installs to still do so, but the > great masses of users (and hosting providers!) who expect the package > called "ruby" to be all of ruby will be spared confusion and > frustration. I completely agree. It's fine for Debian to offer lighter installs, but installing Ruby should mean I get Ruby as it was meant to be. That has to be the default to be correct, in my opinion. James Edward Gray II
From: Brian Candler on 18 Mar 2010 10:36 Lucas Nussbaum wrote: > OpenSSL doesn't have a lot of fans <wikipedia>Citation Needed</wikipedia> (give me BSD-licensed code any day) -- Posted via http://www.ruby-forum.com/.
From: Rick DeNatale on 18 Mar 2010 10:45 On Thu, Mar 18, 2010 at 10:21 AM, Lucas Nussbaum <lucas(a)lucas-nussbaum.net> wrote: > On 18/03/10 at 23:05 +0900, Nick Brown wrote: > In Debian, we do not ship software without appropriately describing what > other packages are required (as dependencies) to use it. ruby1.8-elisp > is a separate package that depends on emacs, so that is fine. But if we > wanted to ship the content of ruby1.8-elisp inside an hypothetical > full-featured ruby package, the right thing to do would be to depend on > emacs. This could become an interesting issue on some of the > architecture debian supports. > >> 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 thought perhaps my disk was going dead on >> me... I eventually figured out what was up after some searching of the >> net, but I think this illustrates the sort of confusion that can arise. > > OpenSSL doesn't have a lot of fans, because of its licence that prevents > it from being linked to GPL software. Yes, it could be possible to ship > openssl.so and readline.so in the same package, but then it would be > harder to argue that Debian does enough to protect the linking of > readline (GPLv2) with openssl. The situation would be much simpler if > Ruby switched to GNU TLS, for example. > >> The easiest way to solve this problem would be to rename "ruby" to >> "ruby-core" or something, then rename "ruby-full" to "ruby". This would >> allow the few who want partial ruby installs to still do so, but the >> great masses of users (and hosting providers!) who expect the package >> called "ruby" to be all of ruby will be spared confusion and >> frustration. > > I really think that this problem is a minor one, and not worth all the > noise around it. I'll see with the other maintainers if there's a way we > can improve the situation slightly. But the licensing issues involved > make me fear that it is unlikely. Really, sometimes the requirements of keeping the packages in a distro in-line are at odds with what some users need to do with the software being packaged. Not trying to be controversial here, but the discussion could be about who owns Jerusalem. The Debian policies are aimed at keeping the overall system under control moving from one consistent set of package versions to another. For some people that works well, even for Ruby. But others have the requirement to treat components in a more flexible way. 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. If packaged Ruby works for someone, fine. For a long time I've been installing Ruby and rubygems from source on my Debian/Ubuntu systems, as well as on my OS X machines, in a directory outside of the territory claimed by the OS, at first manually and now with rvm. If the packaged version of Ruby is used at all on my machines, it's only by other packages which pre-req it, not by code I write. >> 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. -- Rick DeNatale Blog: http://talklikeaduck.denhaven2.com/ Twitter: http://twitter.com/RickDeNatale WWR: http://www.workingwithrails.com/person/9021-rick-denatale LinkedIn: http://www.linkedin.com/in/rickdenatale
From: Lucas Nussbaum on 18 Mar 2010 11:01
On 18/03/10 at 23:36 +0900, Brian Candler wrote: > Lucas Nussbaum wrote: > > OpenSSL doesn't have a lot of fans > > <wikipedia>Citation Needed</wikipedia> > > (give me BSD-licensed code any day) http://en.wikipedia.org/wiki/BSD_licenses#4-clause_license_.28original_.22BSD_License.22.29 (which is the version of the BSD license that OpenSSL uses. If it was the 3-clauses BSD license, there would be no problem.) -- | Lucas Nussbaum | lucas(a)lucas-nussbaum.net http://www.lucas-nussbaum.net/ | | jabber: lucas(a)nussbaum.fr GPG: 1024D/023B3F4F | |