Bug 601633
Summary: | Review Request: rubygem-sup - A console-based email client written in ruby | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Shreyank Gupta <shreyankg> |
Component: | Package Review | Assignee: | Mamoru TASAKA <mtasaka> |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | rawhide | CC: | fedora-package-review, jguiditt, mtasaka, notting |
Target Milestone: | --- | Flags: | mtasaka:
fedora-review+
huzaifas: fedora-cvs+ |
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | rubygem-sup-0.10.2-5.fc13 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2010-06-16 11:48:17 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | 588461, 598980, 602348 | ||
Bug Blocks: |
Description
Shreyank Gupta
2010-06-08 11:17:49 UTC
*** Bug 601641 has been marked as a duplicate of this bug. *** *** Bug 601636 has been marked as a duplicate of this bug. *** Would you update rubygem-net-ssh review request? Also where is rubygem(xapian-full)? (In reply to comment #3) > Would you update rubygem-net-ssh review request? I was talking to the guy who did the review request for rubygem-net-ssh. Could I add a new specfile/srpm on behalf of the requestor? Or do I have to wait until he doesn't respond? > Also where is rubygem(xapian-full)? I will package it as soon as rubygems.org comes back up. I was hoping I could use xapian-bindings-ruby inplace of rubygem(xapian-full), but as it turns out I can't. (In reply to comment #4) > (In reply to comment #3) > > Would you update rubygem-net-ssh review request? > I was talking to the guy who did the review request for rubygem-net-ssh. > Could I add a new specfile/srpm on behalf of the requestor? Or do I have to > wait until he doesn't respond? I think you can submit your new srpm now (because from the response on the other bug it seems the original submitter is busy at the moment). If the original submitter wants to co-maintain net-ssh, we can add him to package owners' list later. > > Also where is rubygem(xapian-full)? > I will package it as soon as rubygems.org comes back up. I was hoping I could > use xapian-bindings-ruby inplace of rubygem(xapian-full), but as it turns out I > can't. Would you check if xapian-bindings-ruby isn't really sufficient? (please check my comments on ruby-sig) UPDATED: --------- Spec URL: http://shreyankg.fedorapeople.org/packaging/sup/sup.spec SRPM URL: http://shreyankg.fedorapeople.org/packaging/sup/sup-0.10.2-2.fc13.src.rpm Notes: ------ * Doing away with rubygems generated bin/* files and using the sup bin/* to not depend on the rubygem dependencies. * Falling back on Requires: xapian-bindings-ruby Koji scratch: --------------- http://koji.fedoraproject.org/koji/taskinfo?taskID=2242063 UPDATED: --------- Spec URL: http://shreyankg.fedorapeople.org/packaging/sup/sup.spec SRPM URL: http://shreyankg.fedorapeople.org/packaging/sup/sup-0.10.2-3.fc13.src.rpm Notes: ------ See changelog. Some notes: * Naming - As this is based on sup "gem", please name rpm as "rubygem-sup" anyway (because installed rpm can be used as sup "gem"). * Explicit version dependency - Usually when a package depends on an other package with specific dependency, if the (latter) package on Fedora satisfies the version dependency on all supported branches, we regards it jus redundant to write such version dependency explicitly. - For example rubygem-mime-types when Fedora 12 is released has EVR "1.16-3.fc11", so we regard writing ">= 1" dependency on "Requires: rubygem(mime-types)" is just redundant Note that this package can be imported on Fedora 12 and above (we cannot add new package on Fedora 11 anymore) * %gemdir/bin scripts treatment - We usually * move files under %gemdir/bin to %_bindir * then just do "rmdir %buildroot/%gemdir" * and don't move files under %geminstdir/bin As you actually modified gemspec file, it should be that scripts under %gemdir/bin can correctly be used ! and anyway "$ ruby -rubygems -e 'gem "sup"' " should succeed. * ncurses dependency - This package installs %geminstdir/lib/ncurses.rb - I don't think this file is needed because ruby-ncurses rpm is to be installed. - Also this file contains ------------------------------------------------------------------ 21 require "ncurses.so" ------------------------------------------------------------------ however ncurses.so cannot be found (note that ruby-ncurses contains %ruby_sitearch/ncurses_bin.so) So please remove this file to avoid confusion. (In reply to comment #9) > Some notes: > > * Naming > - As this is based on sup "gem", please name rpm as "rubygem-sup" > anyway (because installed rpm can be used as sup "gem"). > I am of the opinion, that since this package is not a ruby library, it need not be named as rubygem-sup. Also since this package is a application naming it sup rather than rubygem-sup makes more sense. We already have some other example. - For example rails is not scrictly ruby "library" - Also we have "merb" (I don't know well, maintained by Kent), and (I think) this is not ruby library - haml is also an application But naming these packages as "rubygem-foo" anyway is preferred because we can track easily what packages are built from gem (i.e. it makes easier to maintain). (In reply to comment #11) > We already have some other example. > - For example rails is not scrictly ruby "library" But it still is a web framework. All rails applications have "gem 'rails'" as inside config/boot.rb > - Also we have "merb" (I don't know well, maintained by Kent), and > (I think) this is not ruby library I guess they will be merged into rails 3 > - haml is also an application > It is basically a library to parse views templates written in haml. > But naming these packages as "rubygem-foo" anyway is preferred because > we can track easily what packages are built from gem (i.e. it makes > easier to maintain). If that is the concern could we package sup as rubygem-sup and provide a subpackage sup (something similar to https://fedoraproject.org/wiki/Packaging:Ruby#Packaging_for_Gem_and_non-Gem_use) (In reply to comment #12) > If that is the concern could we package sup as rubygem-sup and provide a > subpackage sup (something similar to > https://fedoraproject.org/wiki/Packaging:Ruby#Packaging_for_Gem_and_non-Gem_use) Or maybe the other way round! :-) I think just "Provides: sup = %{version}-%{release}" is the simplest. Alright then. UPDATED: --------- Spec URL: http://shreyankg.fedorapeople.org/packaging/sup/rubygem-sup.spec SRPM URL: http://shreyankg.fedorapeople.org/packaging/sup/rubygem-sup-0.10.2-4.fc13.src.rpm Please also keep "Provides: rubygem(%{gemname}) = %{version}". --------------------------------------------------------------- This package (rubygem-sup) is APPROVED by mtasaka --------------------------------------------------------------- New Package CVS Request ======================= Package Name: rubygem-sup Short Description: A console-based email client written in ruby Owners: shreyankg Branches: F-13 UPDATED: --------- Spec URL: http://shreyankg.fedorapeople.org/packaging/sup/rubygem-sup.spec SRPM URL: http://shreyankg.fedorapeople.org/packaging/sup/rubygem-sup-0.10.2-5.fc13.src.rpm cvs done rubygem-sup-0.10.2-5.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/rubygem-sup-0.10.2-5.fc13 Closing. rubygem-sup-0.10.2-5.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report. |