On Mon, Sep 3, 2012 at 11:36 AM, Claudio Jeker <cje...@diehard.n-r-g.com> wrote:
> On Sun, Sep 02, 2012 at 11:24:59AM -0700, Jeremy Evans wrote:
>> The following ports have issues with ruby 1.9, are pure ruby gems,
>> are currently unmaintained, and I'd like to remove them from the ports
>> tree:
>>
>> devel/ruby-facets (doesn't run on ruby 1.9)
>> devel/ruby-rparsec (doesn't run on ruby 1.9)
>> devel/ruby-sexp (depends on devel/ruby-rparsec)
>> graphics/ruby-gd2 (doesn't run on ruby 1.9)
>> misc/ruby-spreadsheet (doesn't run on ruby 1.9)
>
> Hmm. I'm using ruby19-spreadsheet-0.6.5.0 and it works for me.
Weird, it should fail due to it's dependence on devel/ruby-ole, which
doesn't work with the new date library used in ruby 1.9.3. I missed
that library in this list, but I would like to remove that as well.
Also, as you mentioned to me, textproc/ruby-prawn has issues with 1.9,
so I'd like to add that to this list as well.
Here's an example of the failure:
$ ruby19 -rspreadsheet -e 'p 1'
/usr/local/lib/ruby/1.9.1/rubygems/custom_require.rb:36:in `require':
iconv will be deprecated in the future, use String#encode instead.
/usr/local/lib/ruby/gems/1.9.1/gems/ruby-ole-1.2.11.1/lib/ole/types/base.rb:78:in
`new': undefined method `new0' for Ole::Types::FileTime:Class
(NoMethodError)
from
/usr/local/lib/ruby/gems/1.9.1/gems/ruby-ole-1.2.11.1/lib/ole/types/base.rb:89:in
`<class:FileTime>'
from
/usr/local/lib/ruby/gems/1.9.1/gems/ruby-ole-1.2.11.1/lib/ole/types/base.rb:60:in
`<module:Types>'
from
/usr/local/lib/ruby/gems/1.9.1/gems/ruby-ole-1.2.11.1/lib/ole/types/base.rb:15:in
`<module:Ole>'
from
/usr/local/lib/ruby/gems/1.9.1/gems/ruby-ole-1.2.11.1/lib/ole/types/base.rb:8:in
`<top (required)>'
from /usr/local/lib/ruby/1.9.1/rubygems/custom_require.rb:36:in
`require'
from /usr/local/lib/ruby/1.9.1/rubygems/custom_require.rb:36:in
`require'
from
/usr/local/lib/ruby/gems/1.9.1/gems/ruby-ole-1.2.11.1/lib/ole/types.rb:1:in
`<top (required)>'
from /usr/local/lib/ruby/1.9.1/rubygems/custom_require.rb:36:in
`require'
from /usr/local/lib/ruby/1.9.1/rubygems/custom_require.rb:36:in
`require'
from
/usr/local/lib/ruby/gems/1.9.1/gems/ruby-ole-1.2.11.1/lib/ole/storage/base.rb:6:in
`<top (required)>'
from /usr/local/lib/ruby/1.9.1/rubygems/custom_require.rb:36:in
`require'
from /usr/local/lib/ruby/1.9.1/rubygems/custom_require.rb:36:in
`require'
from
/usr/local/lib/ruby/gems/1.9.1/gems/ruby-ole-1.2.11.1/lib/ole/storage.rb:1:in
`<top (required)>'
from /usr/local/lib/ruby/1.9.1/rubygems/custom_require.rb:36:in
`require'
from /usr/local/lib/ruby/1.9.1/rubygems/custom_require.rb:36:in
`require'
from
/usr/local/lib/ruby/gems/1.9.1/gems/spreadsheet-0.6.5.0/lib/spreadsheet/excel/writer/workbook.rb:6:in
`<top (required)>'
from /usr/local/lib/ruby/1.9.1/rubygems/custom_require.rb:36:in
`require'
from /usr/local/lib/ruby/1.9.1/rubygems/custom_require.rb:36:in
`require'
from
/usr/local/lib/ruby/gems/1.9.1/gems/spreadsheet-0.6.5.0/lib/spreadsheet/excel/writer.rb:1:in
`<top (required)>'
from /usr/local/lib/ruby/1.9.1/rubygems/custom_require.rb:36:in
`require'
from /usr/local/lib/ruby/1.9.1/rubygems/custom_require.rb:36:in
`require'
from
/usr/local/lib/ruby/gems/1.9.1/gems/spreadsheet-0.6.5.0/lib/spreadsheet/excel/workbook.rb:3:in
`<top (required)>'
from /usr/local/lib/ruby/1.9.1/rubygems/custom_require.rb:36:in
`require'
from /usr/local/lib/ruby/1.9.1/rubygems/custom_require.rb:36:in
`require'
from
/usr/local/lib/ruby/gems/1.9.1/gems/spreadsheet-0.6.5.0/lib/spreadsheet.rb:27:in
`<top (required)>'
from /usr/local/lib/ruby/1.9.1/rubygems/custom_require.rb:60:in
`require'
from /usr/local/lib/ruby/1.9.1/rubygems/custom_require.rb:60:in
`rescue in require'
from /usr/local/lib/ruby/1.9.1/rubygems/custom_require.rb:35:in
`require'
Have you by chance installed an updated ruby-ole via gems? If so and
it works, I'm fine with updating the ruby-ole version in ports and
keeping both ruby-ole and ruby-spreadsheet.
> As a side note, I like to install the gems via packages because then I
> only need to know about one package management utility. At least I know
> that our tools will handle updates and removals properly. At the same time
> I understand that making a new port for every gem is crazy and I stopped
> doing this myself (even though making such a port is easy).
rubygems does a pretty good job here. All gems are installed in
versioned directories, so installing a new version of a gem doesn't
delete the old version (unlike upgrading a package). The worst part
of rubygems updating/removal process is the lack of checksumming, but
that's not a huge issue in most cases.
I agree that having to only deal with packages would be ideal, but I
don't think it's possible. Not just for manpower/bloat reasons, but
because if you deal with a lot of external ruby libraries, you will
eventually need to install two separate versions of the same gem at
the same time. Packages can deal with that with @option
no-default-conflict and manual @conflict markers, but it gets ugly
quickly.
Thanks,
Jeremy
