Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=782560 --- Comment #31 from Todd Zullinger <tmz@xxxxxxxxx> 2012-04-28 11:08:52 EDT --- Hi Vit, (In reply to comment #30) > * The EPEL section is wrong. It has to follow the old guidelines (hm, they are > lost somewhere :/ [1]), so you should update the %{gem_dir} macro: > > %global gem_dir %(ruby -rubygems -e 'puts Gem::dir' 2>/dev/null) > > The rest is OK. Hmm, it sounds like it's more hassle than it's worth to try and support Fedora < 17 and EPEL with the same spec file as we'll need in Fedora >= 17. What I've done for now [since I'm tired of getting broken dep reports for the existing ruby-shadow package -- and it prevented me from moving forward with puppet on Fedora >= 17 :)] is update ruby-shadow with the fixes required to support ruby-1.9.3¹. This removes the pressure to get this review finished up, from my perspective anyway. I don't have a lot of time to work on this, so if someone else has a real need for the rubygem version of the shadow module, please feel free to continue this review. One thing I would ask is that anyone who pushes this into older Fedora or RHEL take great care to ensure that non-gem use remain functional. Anything else would be a regression. > * Detecting version of Ruby is not good practice IMO. What if you have > installed by a chance older version of Ruby on your system and later you will > produce unexpected packages? I know, it will never happen on build system, but > might bite somebody when rebuilding locally. I understand that many ruby developers might have multiple versions of ruby installed. This is not a supported build configuration and those who have this are on their own if they want to build these packages. I don't see any reason to go out of our way and make it more difficult for maintainers by hard-coding the ruby version in the spec file. That makes merging the spec file into older branches far more error-prone than it needs to be, IMO. > > With respect to Fedora 15/16 support, I thought that they were supposed to have > > backported support in ruby/irb/rubygems so that installing to the gemdir would > > allow the module to be used from ruby? This does not work for me: > > > > [root@f16-32 /]# cat /etc/redhat-release > > Fedora release 16 (Verne) > > [root@f16-32 /]# rpm -qa ruby\* > > rubygems-1.8.11-1.fc16.1.noarch > > ruby-libs-1.8.7.358-1.fc16.i686 > > ruby-irb-1.8.7.358-1.fc16.noarch > > rubygem-ruby-shadow-2.1.3-2.fc16.i686 > > ruby-1.8.7.358-1.fc16.i686 > > ruby-rdoc-1.8.7.358-1.fc16.noarch > > [root@f16-32 /]# irb > > irb(main):001:0> require 'shadow' > > LoadError: no such file to load -- shadow > > from (irb):1:in `require' > > from (irb):1 > > from :0 > > You have forgotten one important thing: require 'rubygems' , since rubygems > were not loaded by default in Ruby 1.8. Also 'gem list' is useful command for > basic check if gem is installed and recognized by RubyGems. Ahh. I didn't forget this, I just thought that the gemdir was added to the search path on older Fedora releases. I see now in the guidelines that it is not. It simply means that we'd need to also provide the ruby-shadow package if this was to be built for Fedora < 17. Otherwise, current users of the ruby-shadow package would be broken by an update to the rubygem version. Thanks for all the help with this. If I get some free time, I will try to work on this. But it's not nearly as high on my list now that I have ruby-shadow supporting ruby-1.9 in Fedora >= 17¹. ¹ https://admin.fedoraproject.org/updates/FEDORA-2012-6448/ruby-shadow-1.4.1-16.fc17 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review