Re: [Bug 228345] Re: gem1.9 - require 'rdoc/template' fails - missing dependency
2008/5/27 Lucas Nussbaum [EMAIL PROTECTED]: I'd prefer if it went upstream, if applicable. I feel it is a packaging problem. Gem will not need altering. I've subscribed you to the bug and I'd appreciate your thoughts over there. I'm not sure you understand the rationale for splitting ruby1.9. So that other packages don't pull in stuff they don't need and reduce the perennial dependency problem. However those packages are a minority application. The majority want ruby1.x to include gems, to provide an executable called 'ruby', and supply all the subsiduary tools and they will be (and indeed are) confused if that isn't the case. It already exists, it's called ruby-full: Package: ruby-full [..] Depends: irb, libdbm-ruby, libgdbm-ruby, libopenssl-ruby, libreadline-ruby, rdoc, ri, ruby, ruby1.8-dev Recommends: libtcltk-ruby, ruby-elisp But currently, it pulls ruby1.8, since that's the default version, not ruby1.9. Yes, but that's the problem - one of marketing. Names matter. People expect ruby1.x to provide what they need to use ruby. They don't expect it to be just core ruby. If packagers need smaller packages then they should be the one handling the 'what is the package called' problem, not the poor end user who just wants to develop in ruby. For me ruby1.x should be user facing, pull in everything required to develop in ruby (including gems which is notably missing from your list above). We should have ruby1.x-core for those packagers who need the lighter less fattening alternative (with ruby1.x-core handling the 'alternatives' system properly and providing the 'ruby' symlink). The 'ruby' package needs to be a virtual that pulls the 'current' version, but is satisfied by all the other options (which will include jruby and rubinus before too long). So it is really just a package renaming issue, which is a bit of a pain in the backside, but it will improve the standing of Debian/Ubuntu ruby in the community enormously if it is done. And it sets us up to handle the various interpreter combinations going forward. -- Neil Wilson -- gem1.9 - require 'rdoc/template' fails - missing dependency https://bugs.launchpad.net/bugs/228345 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 228345] Re: gem1.9 - require 'rdoc/template' fails - missing dependency
On 28/05/08 at 08:39 -, Neil Wilson wrote: 2008/5/27 Lucas Nussbaum [EMAIL PROTECTED]: I'm not sure you understand the rationale for splitting ruby1.9. So that other packages don't pull in stuff they don't need and reduce the perennial dependency problem. However those packages are a minority application. The majority want ruby1.x to include gems, to provide an executable called 'ruby', and supply all the subsiduary tools and they will be (and indeed are) confused if that isn't the case. Please refrain from using a minority or the majority if you can't point to real data about that. But there's some real data: popcon. 264545 Ubuntu users have libruby1.8 installed (ie about 50% of all ubuntu users, since the most installed packages have 574294). And 9007 users (1.5% of all Ubuntu users, 3.4% of users having libruby1.8 installed) have libgems-ruby1.8 installed. So the data is pretty clear: most users of ruby in Ubuntu are interested in running ruby apps, not in developing ruby apps. (compare with rdoc1.8: 16493 insts) And the package would still be listed if the user only installed rubygems to do a 'gem update --system', so there's no bias introduced by that. It already exists, it's called ruby-full: Package: ruby-full [..] Depends: irb, libdbm-ruby, libgdbm-ruby, libopenssl-ruby, libreadline-ruby, rdoc, ri, ruby, ruby1.8-dev Recommends: libtcltk-ruby, ruby-elisp But currently, it pulls ruby1.8, since that's the default version, not ruby1.9. Yes, but that's the problem - one of marketing. Names matter. People expect ruby1.x to provide what they need to use ruby. They don't expect it to be just core ruby. If packagers need smaller packages then they should be the one handling the 'what is the package called' problem, not the poor end user who just wants to develop in ruby. For me ruby1.x should be user facing, pull in everything required to develop in ruby (including gems which is notably missing from your list above). We should have ruby1.x-core for those packagers who need the lighter less fattening alternative (with ruby1.x-core handling the 'alternatives' system properly and providing the 'ruby' symlink). That's your opinion. The 'ruby' package needs to be a virtual that pulls the 'current' version, but is satisfied by all the other options (which will include jruby and rubinus before too long). That's hard to do, unfortunately, because of compiled extensions. (you can't just install jruby and expect every ruby app to work) So it is really just a package renaming issue, which is a bit of a pain in the backside, but it will improve the standing of Debian/Ubuntu ruby in the community enormously if it is done. And it sets us up to handle the various interpreter combinations going forward. Such a renaming is not an option for lenny. We can discuss it again for lenny+1. -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | -- gem1.9 - require 'rdoc/template' fails - missing dependency https://bugs.launchpad.net/bugs/228345 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 228345] Re: gem1.9 - require 'rdoc/template' fails - missing dependency
2008/5/28 Lucas Nussbaum [EMAIL PROTECTED]: But there's some real data: popcon. 264545 Ubuntu users have libruby1.8 installed (ie about 50% of all ubuntu users, since the most installed packages have 574294). And 9007 users (1.5% of all Ubuntu users, 3.4% of users having libruby1.8 installed) have libgems-ruby1.8 installed. Not very sound statistics. That's just package installs, and no differentiation between automatic and manual. Ubuntu main contains the ruby-core libraries and installs them by default now. So it hardly surprising to see the core installed by the packaging system to run the ruby scripts contained therein. That is what it is supposed to do. It could be called anything and it wouldn't affect those numbers one little bit. Look at the Rails package. Less than 500 people use Rails according to those statistics. Hardly realistic is it given that the Ruby market is dominated by Rails. There is a reason that gems is in Ruby for 1.9. There is a reason there are 3000 gems in the database and growing. I'm pretty sure it isn't just to spite the Debian Ruby group. -- Neil Wilson -- gem1.9 - require 'rdoc/template' fails - missing dependency https://bugs.launchpad.net/bugs/228345 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 228345] Re: gem1.9 - require 'rdoc/template' fails - missing dependency
On 27/05/08 at 09:58 -, Neil Wilson wrote: 2008/5/24 Lucas Nussbaum [EMAIL PROTECTED]: Right. I'm waiting for your patch. Ok. Lucas. I'm going to send a patch via Ubuntu. Feel free me to subscribe me to the bug. The patch will be to include /var/lib/gems/xxx/bin in the system path within the rubygems module. There are plenty of bugs here on Launchpad complaining about that little 'oversight'. And I know it irritates the very devil out of everybody using Ubuntu Ruby to get real things done. In fact the standard approach is to do a 'gem update --system' after installation to get back to the normal gem infrastructure. If you can get your team to accept that within the Debian rubygems package then we have a fighting chance of moving forward together. I'd prefer if it went upstream, if applicable. If not then there may have to be some sort of fork. Sure. Try to talk to the gems developer about that. I'm sure they will listen to you. You might want to have a look at the ML archives first, though, it's not like we tried. But I'm not going to engage with another hateful discussion with the rubygems developers. I don't find them that bad. But then I have a slightly more pragmatic position with Rubygems and a very, very large itch that I need to scratch. My mistake so far has been to try to reach them through ruby-core. Trying to contact them directly might be more successful, as you will avoid Austin Ziegler. I will talk to Eric, et al and see if we can come to some accommodation. As to the substance of this bug, I can live with the splitting of the Ruby1.9 system into the sub-packages if they are pulled back together into a single point somehow. It would be much better if ruby1.8 and ruby1.9 pulled them all back together again for the average user. I'm not sure you understand the rationale for splitting ruby1.9. Would it not be more sensible to have a ruby1.8-core and ruby1.9-core package to allow minimalist dependencies but incorporate gem1.8 and gem1.9 (along with irb, ri, rdoc) in the ruby1.8/ruby1.9 packages and target them at those developing with the language? It already exists, it's called ruby-full: Package: ruby-full [..] Depends: irb, libdbm-ruby, libgdbm-ruby, libopenssl-ruby, libreadline-ruby, rdoc, ri, ruby, ruby1.8-dev Recommends: libtcltk-ruby, ruby-elisp But currently, it pulls ruby1.8, since that's the default version, not ruby1.9. -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | -- gem1.9 - require 'rdoc/template' fails - missing dependency https://bugs.launchpad.net/bugs/228345 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 228345] Re: gem1.9 - require 'rdoc/template' fails - missing dependency
I think it would be better if Ubuntu started packaging Ruby in the way that people who use it actually require. Explain to a real user why they need to do 'apt-get install gem' rather than 'apt-get install ruby' to be able to use Ruby properly. They look at you daft and go off and use CentOs or Gentoo instead where you can install ruby 1.9 and gem just works. This if you don't like it you can lump it attitude is not at all helpful to those who need to use the distribution to get real things done. - The Ubuntu packages need to support the gem database. For example, currently apt Mongrel does not tell gem that it is installed which stops the mongrel cluster gem installing properly. That requires me to use a compiler in the real world and is a clear example of the failure of the current Debian Ruby binary packaging mechanisms. Apt must keep the gem database up to date if it is a package that has come from Gem so that Gem doesn't get confused and the gem dependencies work for gem packages not in the apt database. - We need a better way of packaging gems with apt - preferably automatically in the majority of cases. That means getting away for the esoteric CDBS Makefile system and embracing Rake which somebody constructing gems can understand and include in their system. Gem is merely a source packaging system like tar with a relatively primitive binary generation system. Apt is so much more powerful. Yet there are 2500 gems and next to no apt packages. That demonstrates the failure of the current packaging model. - The notion that when a system adminstrator installs Gems they *don't* want the binaries on the system path is silly. Packaging is about automation and I'm sick to death of having to do manual alterations to the system path just because of somebody's incorrect idea of how the world is. If gems is installed then the bin needs to go on the system path (at the end - after /usr/games) automatically. On 24/05/2008, Lucas Nussbaum [EMAIL PROTECTED] wrote: Feel free to install ruby from sources if you don't like the way it's packaged in Debian/Ubuntu. So you get the same amount of support for ruby and third party libs you install through gems. No, I think it is time that the packaging system changed to support real users doing real Ruby in the real world. There are plenty of instances where Ubuntu has altered its policy compared to Debian. It is preferable that the two are aligned but where there is a clear problem with the solution offered by Debian then Ubuntu has the option of going in a different direction. That is probably where this is going if a solution can't be worked out. At the end of the day code talks. Nobody in Ruby (which is mostly Rails these days) is seriously using the apt packages currently constructed because they are not fit for purpose. Rails is just completely wrong, Mongrel is deficient as pointed out above, there is no ferret package. I can just about use the database libraries until I need a gem that depends on them - then it all goes pear shaped. Not good enough when your business depends upon it. (Btw, interesting post on this topic: http://www.madstop.com/ruby/ruby_has_a_distribution_problem.html ) That's the usual technique of a clique grasping at information that appear to support their position despite the overwhelming tide of evidence against them. That evidence is Ruby people avoiding Debian and Ubuntu and picking other distributions because their Ruby support is superior, or installing compilers on their servers and using gem because it is just so much easier. What that article is really saying is that we need pragmatic integration between apt and gem now. And that means realising Gem is a *source* repository that just happens to have a simple cross platform binary creator and a dependency system. It has advantages over apt in some cases (allowing multiple versions of Rails on a single system for example), but it useless in other regards (no postinst scripting, appalling native code support and a disregard for FHS). The systems need to work together efficiently and I've got some reasonable well formed thoughts about how that should happened and I know that you're doing something similar because I've been reviewing what you've said in public. So if you're interested in thrashing out a solution we can all work with Lucas, then I'm all ears. Drop me a note offline. -- Neil Wilson -- gem1.9 - require 'rdoc/template' fails - missing dependency https://bugs.launchpad.net/bugs/228345 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 228345] Re: gem1.9 - require 'rdoc/template' fails - missing dependency
On 24/05/08 at 06:29 -, Neil Wilson wrote: I think it would be better if Ubuntu started packaging Ruby in the way that people who use it actually require. Explain to a real user why they need to do 'apt-get install gem' rather than 'apt-get install ruby' to be able to use Ruby properly. They look at you daft and go off and use CentOs or Gentoo instead where you can install ruby 1.9 and gem just works. This if you don't like it you can lump it attitude is not at all helpful to those who need to use the distribution to get real things done. Ah ah. - The Ubuntu packages need to support the gem database. For example, currently apt Mongrel does not tell gem that it is installed which stops the mongrel cluster gem installing properly. That requires me to use a compiler in the real world and is a clear example of the failure of the current Debian Ruby binary packaging mechanisms. Apt must keep the gem database up to date if it is a package that has come from Gem so that Gem doesn't get confused and the gem dependencies work for gem packages not in the apt database. Right. I'm waiting for your patch. - We need a better way of packaging gems with apt - preferably automatically in the majority of cases. That means getting away for the esoteric CDBS Makefile system and embracing Rake which somebody constructing gems can understand and include in their system. Gem is merely a source packaging system like tar with a relatively primitive binary generation system. Apt is so much more powerful. Yet there are 2500 gems and next to no apt packages. That demonstrates the failure of the current packaging model. I'm waiting for your patches here as well. - The notion that when a system adminstrator installs Gems they *don't* want the binaries on the system path is silly. Packaging is about automation and I'm sick to death of having to do manual alterations to the system path just because of somebody's incorrect idea of how the world is. If gems is installed then the bin needs to go on the system path (at the end - after /usr/games) automatically. Here too. Please send a patch. On 24/05/2008, Lucas Nussbaum [EMAIL PROTECTED] wrote: Feel free to install ruby from sources if you don't like the way it's packaged in Debian/Ubuntu. So you get the same amount of support for ruby and third party libs you install through gems. No, I think it is time that the packaging system changed to support real users doing real Ruby in the real world. There are plenty of instances where Ubuntu has altered its policy compared to Debian. It is preferable that the two are aligned but where there is a clear problem with the solution offered by Debian then Ubuntu has the option of going in a different direction. That is probably where this is going if a solution can't be worked out. At the end of the day code talks. Yes, exactly. Stop talking, write a patch. Nobody in Ruby (which is mostly Rails these days) is seriously using the apt packages currently constructed because they are not fit for purpose. It's strange, then, too see Ruby's popcon score. Probably they installed it by mistake. Rails is just completely wrong, Mongrel is deficient as pointed out above, there is no ferret package. I can just about use the database libraries until I need a gem that depends on them - then it all goes pear shaped. Not good enough when your business depends upon it. (Btw, interesting post on this topic: http://www.madstop.com/ruby/ruby_has_a_distribution_problem.html ) That's the usual technique of a clique grasping at information that appear to support their position despite the overwhelming tide of evidence against them. Lol. That evidence is Ruby people avoiding Debian and Ubuntu and picking other distributions because their Ruby support is superior, or installing compilers on their servers and using gem because it is just so much easier. What that article is really saying is that we need pragmatic integration between apt and gem now. And that means realising Gem is a *source* repository that just happens to have a simple cross platform binary creator and a dependency system. It has advantages over apt in some cases (allowing multiple versions of Rails on a single system for example), but it useless in other regards (no postinst scripting, appalling native code support and a disregard for FHS). The systems need to work together efficiently and I've got some reasonable well formed thoughts about how that should happened and I know that you're doing something similar because I've been reviewing what you've said in public. Sure. Try to talk to the gems developer about that. I'm sure they will listen to you. You might want to have a look at the ML archives first, though, it's not like we tried. But I'm not going to engage with another hateful discussion with the rubygems developers. -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/
[Bug 228345] Re: gem1.9 - require 'rdoc/template' fails - missing dependency
The gem command *is* a completely integral part of ruby1.9. Removing it is like removing the standard library or the interpreter itself. nobody is talking about removing gem1.9. It's just going to be packaged separately, to allow other packages to depend only on what they need. There is a great need to start treating gem with the respect that ruby developers expect, rather than this continuing attempt to treat it as some sort of side issue. It's like trying to hold back the tide and is already causing massive problems in using both Debian and Ubuntu as a basis for any sort of Ruby operation. It's deeply frustrating. massive problems? deeply frustrating? Seriously, gem is one apt-get install gem1.9 away. If that causes massive problems and deep frustation to you, you clearly have a problem. Every serious ruby developer has gem installed. Every serious ruby program going forward will use gems. I see no value at all in splitting it out. Feel free to install ruby from sources if you don't like the way it's packaged in Debian/Ubuntu. So you get the same amount of support for ruby and third party libs you install through gems. (Btw, interesting post on this topic: http://www.madstop.com/ruby/ruby_has_a_distribution_problem.html ) -- gem1.9 - require 'rdoc/template' fails - missing dependency https://bugs.launchpad.net/bugs/228345 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 228345] Re: gem1.9 - require 'rdoc/template' fails - missing dependency
This bug was fixed in the package ruby1.9 - 1.9.0.1-1ubuntu1 --- ruby1.9 (1.9.0.1-1ubuntu1) intrepid; urgency=low * Merge from debian unstable, remaining changes: - Robustify check for target_os, fixing build failure on lpia. * debian/control: - ruby1.9 pkg: moved rdoc1.9 suggestion to depends. (LP: #228345) ruby1.9 (1.9.0.1-1) unstable; urgency=low [ akira yamada ] * new upstream snapshot 1.9.0-1. * debian/generated-incs/*: updated. * applied some bug fix patches: - 800_parse_shebang_in_usascii: [ruby-dev:33955] --encoding affects script encoding - 801_too_strict_encoding_check: [ruby-dev:33966] remove too strict encoding check - 802_hash_compare_by_identity: [ruby-dev:33989] Hash#compare_by_identity breaks commutativity of Hash#== - 803_syntaxerror_irb_bug: [ruby-dev:33991] SyntaxError should not be considered as IRB bug - 804_debug.rb_is_bloken: [ruby-dev:33992] debug.rb causes NoMethodError - 805_webrick_file_access_vulnerability: fixes vulnerbility of WEBrick which is described at http://www.ruby-lang.org/en/news/2008/03/03/webrick-file-access-vulnerability/ - 900_ri_pager: updated. [ Lucas Nussbaum ] * debian/control: Added myself to Uploaders:. * debian/control: Added Homepage and Vcs-* fields. * added 909_update_lib_README.dpatch, backported from ruby1.8. * Improved description of ruby1.9-dev. * No longer build using gcc-4.1 on m68k. Use the default gcc version. (Closes: #463294) * debian/control: bumped Standards-Version to 3.7.3. No changes needed. * added watch file. [ Daigo Moriwaki ] * debian/control: - imporoved the description for libopenssl-ruby1.8. - ruby1.9-dev now depends on libc6-dev. -- Stephan Hermann [EMAIL PROTECTED] Fri, 16 May 2008 12:37:06 +0200 ** Changed in: ruby1.9 (Ubuntu) Status: Confirmed = Fix Released -- gem1.9 - require 'rdoc/template' fails - missing dependency https://bugs.launchpad.net/bugs/228345 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 228345] Re: gem1.9 - require 'rdoc/template' fails - missing dependency
Thanks for your report and helping to make ubuntu better. Confirming. ruby 1.9 should depends on rdoc1.9 ** Changed in: ruby1.9 (Ubuntu) Sourcepackagename: None = ruby1.9 Status: New = Confirmed -- gem1.9 - require 'rdoc/template' fails - missing dependency https://bugs.launchpad.net/bugs/228345 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
