Recommended way to install Rubygems
in [Ruby]
|
From: Seebs on 18 Mar 2010 14:28 On 2010-03-18, Austin Ziegler <halostatue(a)gmail.com> wrote: > Please don't repeat this, because as I pointed out on ruby-core, it's > not true. it's not illegal to load libreadline and openssl in the same > process; it's illegal to ship software that contains both. Neither the > OpenSSL license nor the GNU GPL address use or incidental in-memory > copies, only distribution. The issue is, historically, that the FSF has claimed that a program written to use the libreadline API is thereby a "derivative work" of libreadline. A while back, they were arguing that the only way this would be untrue would be if someone were to create a call-compatible "readline" implementation, so that code couldn't be shown to be unable to work without libreadline. Which is funny, because I know of at least one such implementation dating back to 1992. Rich $alz posted it, with these terms: X Permission is granted to anyone to use this software for any purpose on X any computer system, and to alter it and redistribute it freely, subject X to the following restrictions: X 1. The authors are not responsible for the consequences of use of this X software, no matter how awful, even if they arise from flaws in it. X 2. The origin of this software must not be misrepresented, either by X explicit claim or by omission. Since few users ever read sources, X credits must appear in the documentation. X 3. Altered versions must be plainly marked as such, and must not be X misrepresented as being the original software. Since few users X ever read sources, credits must appear in the documentation. X 4. This notice may not be removed or altered. (Yes, it was a shar script.) Long story short: There hasn't been a problem with stuff merely designed to work with readline or something compatible with it since 1992 or possibly earlier. -s -- Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nospam(a)seebs.net http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
From: Lucas Nussbaum on 18 Mar 2010 14:47 On 19/03/10 at 02:49 +0900, Aldric Giacomoni wrote: > > 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. > > Sorry to be a pain for you maintainers. Switch to Gentoo ;-) It handles > all that very well, and has done a fantastic job of handling an overlay > tree for gems - you can essentially get the gems installed and supported > by your distribution. It is of course far from perfect, but they're > doing a fine job of it. > Then again, they have just recently started handling license acceptance > for things like Java, VMWare and such, so Debian is eons ahead of them > in that regard -- which is in fact at the core of our current debate. I think that rubygems and emerge and actually quite similar, which probably explains why they work together well. Rubygems is a great tool for developers who want to get the latest cutting edge software. However, at some point, applications are transferred from developers to sysadmins, and "cutting edge" isn't really a good selling point. Internally (in an organization) it's fine, because you can just vendorize all the gems you use. But if you want to distribute your application to the outside world, it's difficult to explain that the user needs to use rubygems to install that application because it's written in ruby, while the ruby is just interested in the functionality provided by the application, and doesn't care whether it's perl or ruby. I think that approaches that aim at getting rubygems and apt-get to cooperate are just wrong. Both rubygems and apt-get have good reasons to exist, but they don't solve the same problem. Instead, we should try to develop a set of good practices that make it easier to convert a ruby library into a "normal" Deb or RPM package. Much progress has already been done lately, and the last libraries I've packaged didn't use "require 'rubygems'" except in the test suite, so they did not require any patching. We are currently trying to finish the releases for Ubuntu Lucid and Debian Squeeze (in order of appearance ;). After that, it is likely that the way we package ruby libraries in Debian will be discussed with the goal to make it easier to support both ruby 1.8 and 1.9.X (I don't see Ruby 1.8 disappearing during the next 2.5 years). This discussion will also be a good opportunity to discuss other aspects of Ruby packaging. > Besides the issue of licensing mentioned above, the only other real > issue mentioned in this thread is "What will the users think?" or WWUT, > which can clearly be brought back to WWJDIHHAC (What would Jesus do if > he had a computer). JEG II made a change on Ruby's website to help > educating the users. Is it possible to add a message of some sort to the > pre-install apt-get warning when installing Ruby, to explain the > different Ruby packages? I have kind-of done that a few hours ago. Before: # apt-get install ruby Reading package lists... Done Building dependency tree Reading state information... Done The following extra packages will be installed: libruby1.8 ruby1.8 Suggested packages: ruby1.8-examples rdoc1.8 ri1.8 The following NEW packages will be installed: libruby1.8 ruby ruby1.8 0 upgraded, 3 newly installed, 0 to remove and 0 not upgraded. Need to get 2041kB of archives. After this operation, 6644kB of additional disk space will be used. Now: # apt-get install ruby Reading package lists... Done Building dependency tree Reading state information... Done The following extra packages will be installed: libruby1.8 ruby1.8 Suggested packages: irb rdoc ri libopenssl-ruby ruby-dev ruby1.8-examples rdoc1.8 ri1.8 The following NEW packages will be installed: libruby1.8 ruby ruby1.8 0 upgraded, 3 newly installed, 0 to remove and 0 not upgraded. Need to get 2060kB/2082kB of archives. After this operation, 6980kB of additional disk space will be used. (See the list of Suggested packages) It's not much, but still a slight improvement, which should probably have been done before. -- | Lucas Nussbaum | lucas(a)lucas-nussbaum.net http://www.lucas-nussbaum.net/ | | jabber: lucas(a)nussbaum.fr GPG: 1024D/023B3F4F |
From: Leslie Viljoen on 18 Mar 2010 15:26 [Note: parts of this message were removed to make it a legal post.] On Thu, Mar 18, 2010 at 8:47 PM, Lucas Nussbaum <lucas(a)lucas-nussbaum.net>wrote: > On 19/03/10 at 02:49 +0900, Aldric Giacomoni wrote:I think that rubygems > and emerge and actually quite similar, which > probably explains why they work together well. Rubygems is a great tool > for developers who want to get the latest cutting edge software. > However, at some point, applications are transferred from developers to > sysadmins, and "cutting edge" isn't really a good selling point. > Internally (in an organization) it's fine, because you can just > vendorize all the gems you use. But if you want to distribute your > application to the outside world, it's difficult to explain that the > user needs to use rubygems to install that application because it's > written in ruby, while the ruby is just interested in the functionality > provided by the application, and doesn't care whether it's perl or ruby. > Can I ask: how do Perl and Python deal with this? CPAN is included in the base Perl install - how does Perl deal with the fact that CPAN then installs its own stuff? Is it safe to install RubyGems via apt-get now? I have seen warnings but I don't know the actual reason behind them.
From: Aldric Giacomoni on 18 Mar 2010 15:30 Lucas Nussbaum wrote: > On 19/03/10 at 02:49 +0900, Aldric Giacomoni wrote: >> tree for gems - you can essentially get the gems installed and supported >> by your distribution. It is of course far from perfect, but they're >> doing a fine job of it. >> Then again, they have just recently started handling license acceptance >> for things like Java, VMWare and such, so Debian is eons ahead of them >> in that regard -- which is in fact at the core of our current debate. > > I think that rubygems and emerge and actually quite similar, which > probably explains why they work together well. Rubygems is a great tool > for developers who want to get the latest cutting edge software. > However, at some point, applications are transferred from developers to > sysadmins, and "cutting edge" isn't really a good selling point. > > > I think that approaches that aim at getting rubygems and apt-get to > cooperate are just wrong. Both rubygems and apt-get have good reasons to > exist, but they don't solve the same problem. Instead, we should try to > develop a set of good practices that make it easier to convert a ruby > library into a "normal" Deb or RPM package. Much progress has already > been done lately, and the last libraries I've packaged didn't use > "require 'rubygems'" except in the test suite, so they did not require > any patching. > Apt-get does not really handle slotting in the way portage does, and I think that's what you are thinking about when you say that rubygems and portage work the same way. Rubygems isn't meant for what you describe, but I agree that it helps that behavior. Its purpose is to manage different versions of gems because it understands that purposes and APIs can change. Did we mention that gems can be released under whatever license the owner wants? What a nightmare for Debian's apt-get system... I'm glad to hear that it's becoming easier to integrate libs into apt-get. Someone suggested, earlier, that we add ruby to a different branch of the debian sources. How about creating a separate tree for the gems, where the updating can be done more quickly than on the regular tree? Is that idea a no-go because of Debian policies (of which I am blissfully ignorance) ? > >> Is it possible to add a message of some sort to the >> pre-install apt-get warning when installing Ruby, to explain the >> different Ruby packages? > > I have kind-of done that a few hours ago. > > Now: > # apt-get install ruby > Reading package lists... Done > Building dependency tree > Reading state information... Done > The following extra packages will be installed: > libruby1.8 ruby1.8 > Suggested packages: > irb rdoc ri libopenssl-ruby ruby-dev ruby1.8-examples rdoc1.8 ri1.8 > The following NEW packages will be installed: > libruby1.8 ruby ruby1.8 > 0 upgraded, 3 newly installed, 0 to remove and 0 not upgraded. > Need to get 2060kB/2082kB of archives. > After this operation, 6980kB of additional disk space will be used. > > (See the list of Suggested packages) > > It's not much, but still a slight improvement, which should probably > have been done before. That's great - I think it's probably the best way to start. The rest will come down to meetings and long discussions about policies.. :) Now if only users would _read_ ! :p -- Aldric Giacomoni What is the source of conflict? -- Posted via http://www.ruby-forum.com/.
From: Lucas Nussbaum on 18 Mar 2010 16:07
On 19/03/10 at 04:30 +0900, Aldric Giacomoni wrote: > Someone suggested, earlier, that we add ruby to a different branch of > the debian sources. How about creating a separate tree for the gems, > where the updating can be done more quickly than on the regular tree? Is > that idea a no-go because of Debian policies (of which I am blissfully > ignorance) ? You could create an external repository with unofficial (as in: not in Debian) packages that are built automatically from gems. I think that this was actually already done (see http://www.debgem.com/), but I'm not sure of the status of this project. There's nothing blocking anybody from doing that. However, those debs are likely not suitable to be directly integrated in Debian. In Debian, we install Ruby libraries under /usr/lib/ruby/1.8 (with a migration to /usr/lib/ruby/vendor_ruby/1.8 planned, but not done yet, to avoid mixing the stdlib with third-party libs). Also, we make sure that each package works, so an automated process is not going to help us ;) -- | Lucas Nussbaum | lucas(a)lucas-nussbaum.net http://www.lucas-nussbaum.net/ | | jabber: lucas(a)nussbaum.fr GPG: 1024D/023B3F4F | |