Bug 533291
| Summary: | Review Request: ruby-ffi - Foreign Function Interface package for Ruby | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Bryan Kearney <bkearney> |
| Component: | Package Review | Assignee: | Nobody's working on this, feel free to take it <nobody> |
| Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | rawhide | CC: | bkearney, fedora-package-review, notting |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2009-11-24 17:07:24 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: | |||
|
Description
Bryan Kearney
2009-11-05 21:50:46 UTC
Would you consider to create your srpm from gem? It seems that 0.5.1 gem is available on the usual rubyforge gem URL: http://gems.rubyforge.org/gems/%{gemname}-%{version}.gem . If you have some reason to use git based 0.5.2 source, still it is preferable that you create gem archive and install it. Note that while I don't know if 0.5.2 is formally released or not, please refer to Naming guideline: https://fedoraproject.org/wiki/Packaging/NamingGuidelines#Snapshot_packages I did not read the guidelines [1] as requiring a gem. Has that changed? 0.5.2 is released, so I did believe I needed to refer to it as an alpha. [1] https://fedoraproject.org/wiki/Packaging:Ruby (In reply to comment #2) > I did not read the guidelines [1] as requiring a gem. https://fedoraproject.org/wiki/Packaging:Ruby#Packaging_for_Gem_and_non-Gem_use Some trouble happens when someone else want to use ffi gem on Fedora and will try to import ffi gem package into Fedora. In such cases, current Fedora guideline requests that gem based rpm (i.e. rubygem-foo rpm) must be created first and non-gem support (i.e. ruby-foo) must be created as the subpackage of rubygem-foo. gem has some additional usages (although many of them can be replaced by rpm usage) and generally creating rpm from gem (if available) is preferable. (In reply to comment #2) > 0.5.2 > is released, If 0.5.2 is already released formally, please follow https://fedoraproject.org/wiki/Packaging/NamingGuidelines#Post-Release_packages Is the rubygem requirement a hard and fast rule? The current gem does not package the test library, and I think given the nature of this plugin having the ability to run the tests is more valuable then having a gem. Plus, since I already had to patch this earlier in the process, i dont see how building from the gem allows us to add patches to the C code. Unless I pack and pack the gem. -- bk Just following up. this is against standard, but any issues with starting from a tarball and building a gem? This breaks the rubygem source _MUST_ be a gem, but it gets me the test code and test C libraries and I can build the gem from there. -- bk Here is an update. Changes made: * Changed name to rubygem-ffi. * I am still building from the source tarball which is against a "must" rule, but I build them gem from source and then install from it * The version number is not changed since this is not a post release package. This is release 0.5.2. The github UI * rpmlint is clean on the spec and SRPM. One warning on the RPM: [bkearney@localhost ~]$ rpmlint rpmbuild/RPMS/i586/rubygem-ffi-0.5.2-1.fc11.i586.rpm rubygem-ffi.i586: W: hidden-file-or-dir /usr/lib/ruby/gems/1.8/gems/ffi-0.5.2/.require_paths 1 packages and 0 specfiles checked; 0 errors, 1 warnings. * clean koji build: http://koji.fedoraproject.org/koji/taskinfo?taskID=1802185 Updated SRPM: http://bkearney.fedorapeople.org/rubygem-ffi-0.5.2-1.fc11.src.rpm Updated Spec File: http://bkearney.fedorapeople.org/rubygem-ffi.spec Any feedback on the new spec file? Should I kill this bug and re-submit under the new name? -- bk *** This bug has been marked as a duplicate of bug 540996 *** |