Bug 989400 - Review Request: rubygem-mini_portile - Simplistic port-like solution for developers
Review Request: rubygem-mini_portile - Simplistic port-like solution for deve...
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Vít Ondruch
Fedora Extras Quality Assurance
:
Depends On:
Blocks: 989043
  Show dependency treegraph
 
Reported: 2013-07-29 04:25 EDT by Mamoru TASAKA
Modified: 2013-10-04 05:52 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-10-04 05:52:34 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
vondruch: fedora‑review+
limburgher: fedora‑cvs+


Attachments (Terms of Use)

  None (edit)
Description Mamoru TASAKA 2013-07-29 04:25:16 EDT
Spec URL: http://mtasaka.fedorapeople.org/Review_request/rubygem-mini_portile/rubygem-mini_portile.spec
SRPM URL: http://mtasaka.fedorapeople.org/Review_request/rubygem-mini_portile/rubygem-mini_portile-0.5.1-1.fc.src.rpm
Description: 
Simplistic port-like solution for developers. It provides a standard and
simplified way to compile against dependency libraries without messing up
your system.
Fedora Account System Username: mtasaka

Koji scratch build:
F-20 http://koji.fedoraproject.org/koji/taskinfo?taskID=5670886
F-19 http://koji.fedoraproject.org/koji/taskinfo?taskID=5670888
Comment 1 Ken Dreyer 2013-07-29 04:48:57 EDT
Hi Mamoru,

Thanks for submitting the package. Here's a couple questions.

1. In %prep, I haven't seen this "tmpunpackdir" convention in many other gems, and I don't see it referenced in the Ruby packaging guidelines. If this convention is necessary for mini_portile, could you please add a comment to the .spec file indicating why this is necessary?

2. There is a section in %prep where you run "chmod 0644" on all the .rb files. From what I can see by running "gem unpack" by hand on mini_portile-0.5.1.gem, the single .rb file is already 644. In other words, it looks to me as if this step is unnecessary. Can you remove it from your .spec file?

3. From what I read in the current Ruby packaging guidelines, "gem build" is supposed to happen in %build. In your package, it happens in %prep. If there is a reason for this deviation, can you please clarify it in a comment in the .spec?

4. I'm curious about this line:

  %doc	%{gem_instdir}/[A-Z]*

Why not just specify LICENSE.txt explicitly here? From my understanding of the Ruby packaging guidelines, the History.txt and README.rdoc files belong in the -doc subpackage.

5. Regarding these lines:

  # Currently no useful
  %exclude	%{gem_instdir}/examples/

The comment should read "Currently not useful". Also, can you please expand the comment to explain why it would not be useful to ship the example Rakefile in that directory?
Comment 2 Mamoru TASAKA 2013-07-29 05:25:52 EDT
Hello, Thank you for initial comments!

(In reply to Ken Dreyer from comment #1)
> Hi Mamoru,
> 
> Thanks for submitting the package. Here's a couple questions.
> 
> 1. In %prep, I haven't seen this "tmpunpackdir" convention in many other
> gems, and I don't see it referenced in the Ruby packaging guidelines. If
> this convention is necessary for mini_portile, could you please add a
> comment to the .spec file indicating why this is necessary?

This is my convension, to explicitly clarify that unpacking gem file is
done under the directory created by %setup -q -c -T
(i.e. to make it sure that no files are left after %clean is done:
 using %setup after unpacking gem is confusing, and I remember that
 old rpm unpacked source on unexpected directory when %setup was not
 yet called)

> 2. There is a section in %prep where you run "chmod 0644" on all the .rb
> files. From what I can see by running "gem unpack" by hand on
> mini_portile-0.5.1.gem, the single .rb file is already 644. In other words,
> it looks to me as if this step is unnecessary. Can you remove it from your
> .spec file?

For safety. I have seen many times that .rb's have executable permission.

> 3. From what I read in the current Ruby packaging guidelines, "gem build" is
> supposed to happen in %build. In your package, it happens in %prep. If there
> is a reason for this deviation, can you please clarify it in a comment in
> the .spec?

Because I clean up tmpunpack dir. Here I want to make it sure that no garbage files are left. (note that gem build is to repackage gem, and not building something actually)

> 4. I'm curious about this line:
>   %doc	%{gem_instdir}/[A-Z]*
> 
> Why not just specify LICENSE.txt explicitly here? From my understanding of
> the Ruby packaging guidelines, the History.txt and README.rdoc files belong
> in the -doc subpackage.

README.rdoc must be in main (this is why "README" exists). Also it is quite common that "History" file is in main.

> 5. Regarding these lines:
> 
>   # Currently no useful
>   %exclude	%{gem_instdir}/examples/
> 
> The comment should read "Currently not useful". Also, can you please expand
> the comment to explain why it would not be useful to ship the example
> Rakefile in that directory?

Rakefile is something like "Makefile" on autotool-based tarballs, which we don't usually package into binary rpms (also calling "rake" is discouraged in current guideline)
Comment 3 Vít Ondruch 2013-07-30 04:22:35 EDT
(In reply to Mamoru TASAKA from comment #2)
> Hello, Thank you for initial comments!
> 
> (In reply to Ken Dreyer from comment #1)
> > Hi Mamoru,
> > 
> > Thanks for submitting the package. Here's a couple questions.
> > 
> > 1. In %prep, I haven't seen this "tmpunpackdir" convention in many other
> > gems, and I don't see it referenced in the Ruby packaging guidelines. If
> > this convention is necessary for mini_portile, could you please add a
> > comment to the .spec file indicating why this is necessary?
> 
> This is my convension, to explicitly clarify that unpacking gem file is
> done under the directory created by %setup -q -c -T
> (i.e. to make it sure that no files are left after %clean is done:
>  using %setup after unpacking gem is confusing, and I remember that
>  old rpm unpacked source on unexpected directory when %setup was not
>  yet called)

That is good convention. We should similarly update the packaging guidelines. Although it would be worth of some macros, since the things gets a bit ugly.

> > 2. There is a section in %prep where you run "chmod 0644" on all the .rb
> > files. From what I can see by running "gem unpack" by hand on
> > mini_portile-0.5.1.gem, the single .rb file is already 644. In other words,
> > it looks to me as if this step is unnecessary. Can you remove it from your
> > .spec file?
> 
> For safety. I have seen many times that .rb's have executable permission.

If it was me, I would correct only stuff rpmlint reports. Doing some actions without real need is superfluous and does .spec files less readable. But this is not blocker.

> > 3. From what I read in the current Ruby packaging guidelines, "gem build" is
> > supposed to happen in %build. In your package, it happens in %prep. If there
> > is a reason for this deviation, can you please clarify it in a comment in
> > the .spec?
> 
> Because I clean up tmpunpack dir. Here I want to make it sure that no
> garbage files are left. (note that gem build is to repackage gem, and not
> building something actually)

This is related to first point and it does not matter in which section the "build" is done.

> > 4. I'm curious about this line:
> >   %doc	%{gem_instdir}/[A-Z]*
> > 
> > Why not just specify LICENSE.txt explicitly here? From my understanding of
> > the Ruby packaging guidelines, the History.txt and README.rdoc files belong
> > in the -doc subpackage.
> 
> README.rdoc must be in main (this is why "README" exists). Also it is quite
> common that "History" file is in main.

I agree with Ken at this point, but we might disagree. This is not a blocker.

> > 5. Regarding these lines:
> > 
> >   # Currently no useful
> >   %exclude	%{gem_instdir}/examples/
> > 
> > The comment should read "Currently not useful". Also, can you please expand
> > the comment to explain why it would not be useful to ship the example
> > Rakefile in that directory?
> 
> Rakefile is something like "Makefile" on autotool-based tarballs, which we
> don't usually package into binary rpms (also calling "rake" is discouraged
> in current guideline)

This is example in its real sense, i.e. it pretty much corresponds with appropriate section of README.rdoc [1] and it is out of question that it should stay in -doc subpackage. 


[1] https://github.com/luislavena/mini_portile#how-can-i-combine-this-with-my-compilation-task
Comment 4 Mamoru TASAKA 2013-08-06 01:25:06 EDT
Sorry for very late response.

(In reply to Vít Ondruch from comment #3)
> (In reply to Mamoru TASAKA from comment #2)
> > Hello, Thank you for initial comments!
> > 
> > (In reply to Ken Dreyer from comment #1)
> > > Hi Mamoru,
> > > 
> > > Thanks for submitting the package. Here's a couple questions.
> > > 
> > > 1. In %prep, I haven't seen this "tmpunpackdir" convention in many other
> > > gems, and I don't see it referenced in the Ruby packaging guidelines. If
> > > this convention is necessary for mini_portile, could you please add a
> > > comment to the .spec file indicating why this is necessary?
> > 
> > This is my convension, to explicitly clarify that unpacking gem file is
> > done under the directory created by %setup -q -c -T
> > (i.e. to make it sure that no files are left after %clean is done:
> >  using %setup after unpacking gem is confusing, and I remember that
> >  old rpm unpacked source on unexpected directory when %setup was not
> >  yet called)
> 
> That is good convention. We should similarly update the packaging
> guidelines. Although it would be worth of some macros, since the things gets
> a bit ugly.

"That" is _my_ ? Anyway actually old rpm behavior _does_ cause issues when %setup is not done beforehand, now I really recalled this:

http://www.redhat.com/archives/rhl-devel-list/2008-February/msg02054.html

It is much preferable that
* %setup is done first
* all %prep action is guaranteed to be done under the directory that %prep is created

And I don't think this is a blocker.

> > > 3. From what I read in the current Ruby packaging guidelines, "gem build" is
> > > supposed to happen in %build. In your package, it happens in %prep. If there
> > > is a reason for this deviation, can you please clarify it in a comment in
> > > the .spec?
> > 
> > Because I clean up tmpunpack dir. Here I want to make it sure that no
> > garbage files are left. (note that gem build is to repackage gem, and not
> > building something actually)
> 
> This is related to first point and it does not matter in which section the
> "build" is done.

See above. 


> > > 5. Regarding these lines:
> > > 
> > >   # Currently no useful
> > >   %exclude	%{gem_instdir}/examples/
> > > 
> > > The comment should read "Currently not useful". Also, can you please expand
> > > the comment to explain why it would not be useful to ship the example
> > > Rakefile in that directory?
> > 
> > Rakefile is something like "Makefile" on autotool-based tarballs, which we
> > don't usually package into binary rpms (also calling "rake" is discouraged
> > in current guideline)
> 
> This is example in its real sense, i.e. it pretty much corresponds with
> appropriate section of README.rdoc [1] and it is out of question that it
> should stay in -doc subpackage. 

Yeah, this is really "example" Rakefile, good to be in -doc. I will fix this when I import this into Fedora git (unless there is anything to be fixed beforehand)
Comment 5 Vít Ondruch 2013-08-29 05:38:47 EDT
(In reply to Mamoru TASAKA from comment #4)
> "That" is _my_ ? Anyway actually old rpm behavior _does_ cause issues when
> %setup is not done beforehand, now I really recalled this:
> 
> http://www.redhat.com/archives/rhl-devel-list/2008-February/msg02054.html
> 
> It is much preferable that
> * %setup is done first
> * all %prep action is guaranteed to be done under the directory that %prep
> is created
> 
> And I don't think this is a blocker.

Ah, up until now, I thought you are workarounding different problem. In that case, I must say I am not fond of this approach, since I very much prefer mock, which will never suffer this issue. But if you think it helps, it is not a blocker for me (I am not fan of this gem rebuild stuff anyway).

Otherwise the package looks good => APPROVED. Please fix the Rakefile example prior importing.
Comment 6 Mamoru TASAKA 2013-08-30 05:20:53 EDT
Thank you!

New Package SCM Request
=======================
Package Name: rubygem-mini_portile
Short Description: Simplistic port-like solution for developers
Owners: mtasaka
Branches: f18 f19 f20
InitialCC:
Comment 7 Gwyn Ciesla 2013-08-30 08:00:43 EDT
Git done (by process-git-requests).
Comment 8 Mamoru TASAKA 2013-10-04 05:52:34 EDT
Already imported, closing. Thank you for review.

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