Bug 823338 - Review Request: rubygem-moneta - unified interface for key/value stores
Review Request: rubygem-moneta - unified interface for key/value stores
Status: CLOSED DEFERRED
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Josef Stribny
Fedora Extras Quality Assurance
:
Depends On:
Blocks: 823352
  Show dependency treegraph
 
Reported: 2012-05-20 20:15 EDT by Jonas Courteau
Modified: 2016-01-04 00:50 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-01-03 12:53:23 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jonas Courteau 2012-05-20 20:15:18 EDT
Spec URL: https://raw.github.com/jcourteau/rubygems-rpms/master/fc17/rubygem-moneta/rubygem-moneta.spec
SRPM URL: http://rpms.courteau.org/fedora/rubygem-moneta-0.6.0-1.fc17.src.rpm

Description: A unified (ruby) interface to key/value stores

This is part of a set of dependencies for rubygem-chef.  I've got about 14 packages to add, all ruby gems, and am looking for a sponsor.  Several of the packages were previously in Fedora (F11 and F12), but were removed due to lack of a maintainer.
Comment 1 Vít Ondruch 2012-05-21 03:49:10 EDT
Please note that rubygem-moneta was already in Fedora: https://admin.fedoraproject.org/pkgdb/acls/name/rubygem-moneta but has been retired.
Comment 2 Julian C. Dunn 2012-11-25 11:49:42 EST
Since Jonas seems to no longer be working on these, I'm taking them over slowly. Here's my spec & SRPM that I propose to use to undeprecate rubygem-moneta: can you please review:

http://fedorapeople.org/~jdunn/rubygem-moneta/rubygem-moneta.spec
http://fedorapeople.org/~jdunn/rubygem-moneta/rubygem-moneta-0.6.0-2.fc19.src.rpm

Again, I'm only planning to support EPEL6, not EPEL5, in addition to the Fedoras.
Comment 3 Josef Stribny 2012-12-13 11:17:36 EST
I will take this for a review.
Comment 4 Josef Stribny 2012-12-13 11:57:32 EST
1, Please move these files to -doc sub-package (they should not be part of the main package):

%doc %{gem_instdir}/README
%doc %{gem_instdir}/TODO

2, And exclude gem cache from the package using %exclude macro:

%exclude %{gem_cache}

3, Tests should be part of this spec file alongside with the %check section, but I played with the upstream specs and they already differ too much to be tweaked for this version of the gem.

Rpmlint gives me no errors, package builds in mock and the package looks good otherwise.
Comment 5 Julian C. Dunn 2012-12-13 13:21:52 EST
Thanks Josef. I've updated the spec and SRPM for points 1 and 2.

http://fedorapeople.org/~jdunn/rubygem-moneta/rubygem-moneta.spec
http://fedorapeople.org/~jdunn/rubygem-moneta/rubygem-moneta-0.6.0-3.fc19.src.rpm

Re point 3, I had the same problem with the spec tests. Looks like upstream did a lot more work on the specs after 0.6.0 was released but I couldn't get the ones tagged 0.6.0 to work.
Comment 6 Vít Ondruch 2012-12-14 04:16:47 EST
Jonas, first of all, have you considered to replace moneta by juno [1] or something similar? I would say that this package is unmaintained by upstream and should not get into Fedora.

Otherwise, a few comments:

* Please drop the "Requires: ruby"
  - Since we are going to share gems between JRuby and Ruby in F19, it would
    pull in MRI even if not needed.

* Test suite
  - I guess the test suite was developed for RSpec 1.x while you are trying to
    run it with RSpec 2.x. The shared examples are typically troublesome.
  - I am not going to dig more into it, but would you please mind to keep the
    disabled %check section with appropriate comment in .spec file? It would
    help during future updates (if there every will be some) to easily uncomment
    and see what is the state of test suite.


[1] https://github.com/minad/juno
Comment 7 Josef Stribny 2012-12-14 05:48:28 EST
Just a note regarding the test suite: It expects modules that have been added to the repository after the gem has been released (and the structure of the lib folder changed as well), so this is not a problem (or just a problem) with version of RSpec.
Comment 8 Vít Ondruch 2012-12-14 06:48:59 EST
(In reply to comment #6)
> Jonas, 

Ups, sorry s/Jonas/Julian/
Comment 9 Vít Ondruch 2012-12-14 06:52:14 EST
Actually, there is upstream ticket [1] to drop this dependency. Julian, could you please try to push Chef upstream a bit? Thank you.
Comment 10 Julian C. Dunn 2012-12-16 16:04:12 EST
(In reply to comment #9)
> Actually, there is upstream ticket [1] to drop this dependency. Julian,
> could you please try to push Chef upstream a bit? Thank you.

I will push them. It looks like there is an open ticket about this upstream, http://tickets.opscode.com/browse/CHEF-2984

Is it an absolute blocker to not have moneta in Fedora? I notice it used to be there and just got deprecated.
Comment 11 Julian C. Dunn 2012-12-16 16:36:06 EST
(In reply to comment #6)
> Jonas, first of all, have you considered to replace moneta by juno [1] or
> something similar? I would say that this package is unmaintained by upstream
> and should not get into Fedora.
> 
> Otherwise, a few comments:
> 
> * Please drop the "Requires: ruby"
>   - Since we are going to share gems between JRuby and Ruby in F19, it would
>     pull in MRI even if not needed.
> 
> * Test suite
>   - I guess the test suite was developed for RSpec 1.x while you are trying
> to
>     run it with RSpec 2.x. The shared examples are typically troublesome.
>   - I am not going to dig more into it, but would you please mind to keep the
>     disabled %check section with appropriate comment in .spec file? It would
>     help during future updates (if there every will be some) to easily
> uncomment
>     and see what is the state of test suite.

I have fixed these in the latest SPEC and SRPM on my fedorapeople page.

http://fedorapeople.org/~jdunn/rubygem-moneta/rubygem-moneta-0.6.0-3.fc19.src.rpm
http://fedorapeople.org/~jdunn/rubygem-moneta/rubygem-moneta.spec

Everything is in the spec to run the tests if they ever get fixed, but the %check section is commented out with an explanation.
Comment 12 Vít Ondruch 2012-12-17 03:34:16 EST
(In reply to comment #10)
> I will push them. It looks like there is an open ticket about this upstream,
> http://tickets.opscode.com/browse/CHEF-2984

Yes, that is the link I wanted to reference by my [1], but I missed it then ;)
 
> Is it an absolute blocker to not have moneta in Fedora? I notice it used to
> be there and just got deprecated.

I know it was in Fedora. At that time, it also could look that it is maintained etc. But it does not make sense to review some package which is already deprecated and there is a chance that it will be replaced by something else pretty soon.

So instead of doing two reviews, it may have be better to spend some time adapting Chef to used juno instead or drop the dependency entirely, as is referred in [2].

Also, I am afraid that there will be other blockers, such as rubygem-yajl-ruby, so there is no need to rush this review.

So no, it is not absolute blocker, but I think we should try to do it better.

[2] http://tickets.opscode.com/browse/CHEF-2591
Comment 13 Josef Stribny 2012-12-18 04:21:07 EST
I pulled a request to change Moneta dependency and use Juno instead [1].

[1] https://github.com/opscode/chef/pull/552
Comment 14 Julian C. Dunn 2012-12-18 10:11:41 EST
(In reply to comment #13)
> I pulled a request to change Moneta dependency and use Juno instead [1].
> 
> [1] https://github.com/opscode/chef/pull/552

Awesome, thanks Josef!
Comment 15 Josef Stribny 2013-01-03 04:54:06 EST
Julian, 

they released Juno under Moneta in the end [1], but Chef finally dropped the dependency of Moneta [2] so we don't need to pack it for Chef 11 (next release). Perhaps you can close this bug for now as deferred.

[1] https://github.com/opscode/chef/pull/552
[2] https://github.com/opscode/chef/pull/566
Comment 16 Julian C. Dunn 2013-01-03 12:53:23 EST
Josef, I agree with you -- I will close this as DEFERRED.

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