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

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 address hidden> Fri, 16 May 2008 12:37:06 +0200

On 16/05/08 at 12:36 -0000, Ubuntu Merge-o-Matic wrote:
> Changes:
> 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.

OK, will merge that one in the Debian package.

> * debian/control:
> - ruby1.9 pkg: moved rdoc1.9 suggestion to depends. (LP: #228345)

That's wrong. The right solution is to make gem1.9 not part of ruby1.9.

The consequence of your change is that every user of an app written in
ruby (1.9) now installs an additional and useless (for them) 1MB package.
--
| Lucas Nussbaum
| <email address hidden> http://www.lucas-nussbaum.net/ |
| jabber: <email address hidden> GPG: 1024D/023B3F4F |

Hi,

On Fri, 16 May 2008 15:40:50 +0200
Lucas Nussbaum <email address hidden> wrote:

> On 16/05/08 at 12:36 -0000, Ubuntu Merge-o-Matic wrote:
> > Changes:
> > 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.
>
> OK, will merge that one in the Debian package.

Comes from Matthias Klose ( not my idea ;))

>
> > * debian/control:
> > - ruby1.9 pkg: moved rdoc1.9 suggestion to depends. (LP:
> > #228345)
>
> That's wrong. The right solution is to make gem1.9 not part of
> ruby1.9.
>
> The consequence of your change is that every user of an app written in
> ruby (1.9) now installs an additional and useless (for them) 1MB
> package.

I can revert the change...or we are going to fix it directly in debian?!

regards,

\sh

The gem command *is* a completely integral part of ruby1.9. Removing
it is like removing the standard library or the interpreter itself.

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.

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.

2008/5/16 Lucas Nussbaum <email address hidden>:
> On 16/05/08 at 12:36 -0000, Ubuntu Merge-o-Matic wrote:
>> Changes:
>> 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.
>
> OK, will merge that one in the Debian package.
>
>> * debian/control:
>> - ruby1.9 pkg: moved rdoc1.9 suggestion to depends. (LP: #228345)
>
> That's wrong. The right solution is to make gem1.9 not part of ruby1.9.
>
> The consequence of your change is that every user of an app written in
> ruby (1.9) now installs an additional and useless (for them) 1MB package.
> --
> | Lucas Nussbaum
> | <email address hidden> http://www.lucas-nussbaum.net/ |
> | jabber: <email address hidden> 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 direct subscriber
> of the bug.
>

--
Neil Wilson

> 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 )

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 address hidden> 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_...

On 24/05/08 at 06:29 -0000, 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 address hidden> 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. Proba...

2008/5/24 Lucas Nussbaum <email address hidden>:
> Right. I'm waiting for your patch.

Ok. Lucas. I'm going to send a patch via Ubuntu. 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.

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.

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.

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?

Let me know what you think on that last point.

--
Neil Wilson

On 27/05/08 at 09:58 -0000, Neil Wilson wrote:
> 2008/5/24 Lucas Nussbaum <email address hidden>:
> > 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 address hidden> http://www.lucas-nussbaum.net/ |
| jabber: <email address hidden> GPG: 1024D/023B3F4F |

2008/5/27 Lucas Nussbaum <email address hidden>:
> 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

On 28/05/08 at 08:39 -0000, Neil Wilson wrote:
> 2008/5/27 Lucas Nussbaum <email address hidden>:
> > 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 address hidden> http://www.lucas-nussbaum.net/ |
| jabber: <email address hidden> GPG: 1024D/023B3F4F |

2008/5/28 Lucas Nussbaum <email address hidden>:
> 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