Bug 220683

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...

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

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?

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.

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... 

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

If that's done, please include the text of the reply from upstream in the
package as well.

(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

(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. 

Thanks for the review. Successfully imported and built as plague job #25363

Package Change Request
======================
Package Name: rubygems
[New Branches: ] EL-5

cvs done. 

Package Change Request
======================
Package Name: rubygems
Owner: kanarip
[New Branches: ] EL-4

cvs done.