Bug 220683 - Review Request: rubygems - the Ruby standard for packaging ruby libraries
Review Request: rubygems - the Ruby standard for packaging ruby libraries
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Kevin Fenzi
Fedora Package Reviews List
:
Depends On:
Blocks: FE-ACCEPT
  Show dependency treegraph
 
Reported: 2006-12-22 20:37 EST by David Lutterkort
Modified: 2013-04-30 19:40 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-01-17 21:14:57 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
kevin: fedora‑cvs+


Attachments (Terms of Use)

  None (edit)
Description David Lutterkort 2006-12-22 20:37:42 EST
Spec URL: http://people.redhat.com/dlutter/yum/spec/rubygems.spec
SRPM URL: http://people.redhat.com/dlutter/yum/SRPMS/rubygems-0.9.0-1.src.rpm
Description: RubyGems is the Ruby standard for publishing and managing third party 
libraries.

NOTE: While the guidelines currently don't allow packaging of ruby gems, this package is *not* a gem, it contains the libraries/utilities needed to deal with gems, and is packaged like any other ruby package.
Comment 1 Kevin Fenzi 2006-12-28 00:13:49 EST
OK - Package meets naming and packaging guidelines
OK - Spec file matches base package name.
see below - Spec has consistant macro usage.
OK - Meets Packaging Guidelines.
See below - License
See below - License field in spec matches
See below - License file included in package
OK - Spec in American English
OK - Spec is legible.
OK - Sources match upstream md5sum:
5d496e1f415b8b4033ab867f01d1161f  rubygems-0.9.0.tgz
5d496e1f415b8b4033ab867f01d1161f  rubygems-0.9.0.tgz.1
OK - BuildRequires correct
See below - Package has %defattr and permissions on files is good.
OK - Package has a correct %clean section.
OK - Package has correct buildroot
OK - Package is code or permissible content.
OK - Packages %doc files don't affect runtime.

OK - Package compiles and builds on at least one arch.
OK - Package has no duplicate files in %files.
OK - Package doesn't own any directories other packages own.
OK - Package owns all the directories it creates.
OK - No rpmlint output.
OK - final provides and requires are sane:

SHOULD Items:

OK - Should build in mock.
OK - Should build on all supported archs
OK - Should have dist tag
OK - Should package latest version

Issues:

1. You seem to be mixing
%{buildroot}
and
$RPM_BUILD_ROOT
best to pick one macro style and stick with it.

2. What is the license here?
The web page says: License: Ruby License

Your spec says "GPL"

The source files all say: "# See LICENSE.txt for permissions."
There is no included LICENSE.txt file.

3. Might change
%defattr(-, root, root)
to
%defattr(-, root, root,-)

4. The i386 and x86_64 packages are different, which if this should really be
noarch. I see in them: 

/usr/lib/ruby/gems/

/usr/lib64/ruby/gems/

5. Do you need the 'ruby' BuildRequires since you have ruby-devel?
That should pull that in I would think...
Comment 2 David Lutterkort 2007-01-02 19:48:54 EST
Thanks for the review. Issues:

1. Changed to use $RPM_BUILD_ROOT everywhere
2. It's actually dual licensed (Ruby + GPL); no license texts are included in
the distribution tarball. I opened a bug upstream to include them. I changed the
license field to be the same as the one for ruby - rpmlint doesn't like it, but
it's at least consistent now.
3. Changed
4. Good catch - fixed, should now always be /usr/lib/ruby/gems
5. You do need the ruby BR - there's no ruby-devel BR

New files uploaded:
Spec URL: http://people.redhat.com/dlutter/yum/spec/rubygems.spec
SRPM URL: http://people.redhat.com/dlutter/yum/SRPMS/rubygems-0.9.0-2.src.rpm
Comment 3 Kevin Fenzi 2007-01-03 20:19:02 EST
1. ok.
 
2. ok. Yeah, it's really not possible to tell currently what the license is
based on just looking at the package as shipped. ;( 
Do you know when they might address this? I hate to approve and ship the package
without a known for sure license. I wish they would have at least said in the
package that the license was ruby/GPL, but they didn't. 

3. ok. 

4. ok, looks good here. 

5. ah, ok. Not sure why I was thinking that there was one. 

So the blocker I see left is including the license... do you think that will
occur pretty soon?
Comment 4 David Lutterkort 2007-01-05 12:22:11 EST
To thet best of my knowledge, teh guidelines only require that the license is
included in the rpm if it is distributed by upstream in the tarball - the lack
of a license file should therefore not block this review. 

There's been nothing but crickets so far on my request to add the license to the
tarball, so it might be a little bit before upstream fixes it.
Comment 5 Kevin Fenzi 2007-01-05 14:54:53 EST
In reply to comment #4: 

>To thet best of my knowledge, teh guidelines only require that the license is
>included in the rpm if it is distributed by upstream in the tarball - the lack
>of a license file should therefore not block this review. 

Correct... my concern isn't that the license text isn't included, it's that
there is nothing at all in the package referring to what the license _is_.
Everything says 'see LICENSE.txt'.

Not to say that it would happen, but they could ship a LICENSE.txt in the next
release that was not acceptable for extras, and say 'Thats what we always meant". 

>There's been nothing but crickets so far on my request to add the license to
>the tarball, so it might be a little bit before upstream fixes it.

Anoying. :( 
I'll try and think of how we can address this... 
Comment 6 Josh Boyer 2007-01-05 14:59:45 EST
Suggestion:  Email the project asking them exactly what the license is (a URL to
it is fine), copy that to a file named LICENSE.txt, and include it in the
package as a Source1: LICENSE.txt
Comment 7 Jason Tibbitts 2007-01-05 15:09:03 EST
If that's done, please include the text of the reply from upstream in the
package as well.
Comment 8 David Lutterkort 2007-01-05 20:34:07 EST
(In reply to comment #5)

> Correct... my concern isn't that the license text isn't included, it's that
> there is nothing at all in the package referring to what the license _is_.
> Everything says 'see LICENSE.txt'.
> 
> Not to say that it would happen, but they could ship a LICENSE.txt in the next
> release that was not acceptable for extras, and say 'Thats what we always meant". 

Ok, now I understand the concern; the actual LICENSE.txt file is in their
subversion repo [1] and starts by saying
<quote>
RubyGems is copyrighted free software by Chad Fowler, Rich Kilmer, Jim
Weirich and others.  You can redistribute it and/or modify it under
either the terms of the GPL (see COPYING.txt file), or the conditions
below: ...
</quote>

Does that address the concerns around the official license ?

[1]
http://rubyforge.org/viewvc/trunk/LICENSE.txt?revision=1060&root=rubygems&view=markup
Comment 9 Kevin Fenzi 2007-01-05 22:57:01 EST
(In reply to comment #8)

Ah, I didn't think to look in svn... 

that does indeed address my concerns. I was worried that they never had a
LICENSE.txt file, so it could be anything. If they just neglected to ship it in
their files thats not nearly as bad. ;)

That solved, I see no further blockers, so this package can be APPROVED. 
Don't forget to close this NEXTRELEASE once it's been imported and built. 
Comment 10 David Lutterkort 2007-01-09 15:19:19 EST
Thanks for the review. Successfully imported and built as plague job #25363
Comment 11 David Lutterkort 2007-08-31 15:07:53 EDT
Package Change Request
======================
Package Name: rubygems
[New Branches: ] EL-5
Comment 12 Kevin Fenzi 2007-08-31 21:58:33 EDT
cvs done. 
Comment 13 Jeroen van Meeuwen 2009-07-26 06:58:09 EDT
Package Change Request
======================
Package Name: rubygems
Owner: kanarip
[New Branches: ] EL-4
Comment 14 Kevin Fenzi 2009-07-26 15:47:51 EDT
cvs done.

Note You need to log in before you can comment on or make changes to this bug.