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=746438 --- Comment #3 from Vít Ondruch <vondruch@xxxxxxxxxx> 2011-11-28 10:02:45 EST --- (In reply to comment #2) > > * Is it worth of including ruby- subpackage? > > - Isn't this re-review good opportunity to get rid of the ruby- subpackage? > > The design is flawed IMO and doesn't bring anything of benefit for users. > > - Still packages rebuilt from ruby-gnome2 srpm needs this. > Note that ruby-gnome2 uses ruby-gnome2-all "tarball", not gem, and > ruby modules built from ruby-gnome2-all tarball needs ruby-cairo module > and so on. Ok, let's keep it this way for now, but I'll be back as soon as R1.9 hits rawhide, since then the RubyGems gets loaded by default => the ruby- subpackage will be obsolete anyway. > > * Remove the -devel subpackage. > > - Is the -devel package required? Will somebody prepare some other library > > with > > binary extension which will depend on cairo? What is your opinion? > > - Actually, for example: > > http://pkgs.fedoraproject.org/gitweb/?p=rubygem-gtk2.git;a=blob;f=rubygem-gtk2.spec > Ok, I thought there will be some gotcha. > > * defattr macros are no longer necessary > > - https://fedoraproject.org/wiki/Packaging:Guidelines#File_Permissions > > - Will remove. > > > * Use ruby(rubygems) virtual provide preferably > > - Well, for "BR (or R) rubygems" (not rubygem-foo), I decided not to impose > me (and other packagers) to change it to ruby(rubygems) - as actually > (except for %check section) what we use here is gem "command" (i.e. > /usr/bin/gem) and we don't use rubygem "module" (i.e. we don't use > 'require "rubygems"' here). So currently I think writing "BR: rubygems" is > more proper. Actually it doesn't matter that much, however I have some concerns: * I am not 100% sure that "rubygems" package follows the Ruby packaging guidelines, therefore I was considering to rename the package to ruby-rubygems during my R1.9 packaging activities (but at the end I decided to *stay* with 'rubygems'). However, it the package rename happens one day, the require might get broken, therefore I suggest the virtual require. * Mixing ruby(rubygems) and rubygems makes harder to find all packages which depends on RubyGems * If you are interested just in "gem" command, and that is very valid point, then I have to counter propose to use Require: "/usr/bin/gem" since that is what you want to achieve Clearly this is gray area of guidelines. I don't consider this to be a blocker. However, I am interested in finding right solution and codifying it for future. > > * The license should be Ruby or GPLv2 > > - Since the COPYING file states "distributed under the same conditions as > > ruby", > > the license should be adjusted appropriately. > > - Note that /usr/share/doc/ruby-libs-1.8.7.352/COPYING > (in ruby-libs-1.8.7.352-3.fc17.i686) says: > ------------------------------------------------------- > You can redistribute it and/or modify it under either the terms of the GPL > *version 2* (see the file GPL), or the conditions below: > ------------------------------------------------------- > (the explicit *version 2* is here) and this COPYING file says: > ------------------------------------------------------- > You can redistribute it and/or modify it under either the terms of the GPL > (see the file GPL), or the conditions below: > ------------------------------------------------------- > So these are in fact slightly different. This type of difference > actually appear on many ruby gems. How we should interpret may be > ambiguous, however for now for this case I distinguish between > "GPLv2 or Ruby" and "GPL+ or Ruby". Yes, there is definitely ambiguity. However, since in ruby.spec stays "GPLv2 or Ruby" and we distribute the gem with this version of Ruby, I would say that the license should be the same as we state for Ruby itself. Not mentioning that if you use this gem with Ruby 1.9.3, then the gem would be BSD or Ruby licensed. But I am afraid that only upstream can clarify what they actually meant by this license. -- 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