Spec URL: http://mtasaka.fedorapeople.org/Review_request/rubygem-cairo/rubygem-cairo.spec SRPM URL: http://mtasaka.fedorapeople.org/Review_request/rubygem-cairo/rubygem-cairo-1.10.1-1.fc.src.rpm Description: Ruby bindings for cairo. Cairo is a 2D graphics library with support for multiple output devices. Currently supported output targets include the X Window System, win32, and image buffers. Scratch build on koji: f17: http://koji.fedoraproject.org/koji/taskinfo?taskID=3433454 f16: http://koji.fedoraproject.org/koji/taskinfo?taskID=3433472 Well, when I tried to upgrade rubygem-cairo, I noticed that rubygem-cairo was already orphaned ... I don't know why. This is re-review request to make rubygem-cairo included into Fedora again.
* Update to the latest version - Time is passing fast, could you please update to the latest version? * 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. * 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? * defattr macros are no longer necessary - https://fedoraproject.org/wiki/Packaging:Guidelines#File_Permissions * Use ruby(rubygems) virtual provide preferably * 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.
Thank you for comments. I will update my package later. For now only replying to your comments. (In reply to comment #1) > * Update to the latest version > - Time is passing fast, could you please update to the latest version? - Will do later. > * 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. > * 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 > * 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. > * 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".
(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.
Will update later (maybe in a day, or in several days...)
http://mtasaka.fedorapeople.org/Review_request/rubygem-cairo/rubygem-cairo.spec http://mtasaka.fedorapeople.org/Review_request/rubygem-cairo/rubygem-cairo-1.10.2-1.fc.src.rpm * Wed Nov 30 2011 Mamoru Tasaka <mtasaka> - 1.10.2-1 - 1.10.2 - Make dependency for pkg-config be development only again - Change the license tag to "GPLv2 or Ruby" - Remove defattr
The package looks good, so it is APPROVED. However rpmlint reports some minor nits: rubygem-cairo.src: W: strange-permission cairo-1.10.2.gem 0600L rubygem-cairo.src:256: W: mixed-use-of-spaces-and-tabs (spaces: line 256, tab: line 1) And I realized, that it might be good idea to note in comment that the package is distributed "under the same license as Ruby", since the license should probably change with Ruby 1.9.3. OT: May be I should add special macro for this in Ruby 1.9.3 package? Please fix this minor mints before commit.
Thank you for the review! (In reply to comment #6) > And I realized, that it might be good idea to note in comment that the package > is distributed "under the same license as Ruby", since the license should > probably change with Ruby 1.9.3. OT: May be I should add special macro for this > in Ruby 1.9.3 package? I think it is better that this is discussed on ruby list. Package Change Request ====================== Package Name: rubygem-cairo New Branches: devel f16 f15 Owners: mtasaka Note: unretirement request
Unretired all branches, none need creating, please take ownership in pkgdb.
Note that Matz says in 2006: http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-dev/29846 - "Same as Ruby's" should be interpreted as the <current> "Ruby's license". As it does not say explicitly that the license follows the new one automatically, it should be the only reasonable interpretation. <snip> It is up to the judgment of authors of each project whether it follows the new Ruby license. So currently "Same as Ruby" should be interpreted as "GPLv2 or Ruby" in most cases, I guess.
Hello, scm admin: F-16 ownership seems strange, would you check it again? Thank you.
Indeed. I took it and released it, try removing yourself as comaintainer and then taking it.
Okay, now I took the ownership correctly, thank you.
Packages now successfully imported into F17/F16-testing/F15-testing. Thank you for the review and scm procedure, closing.