On 02/20/2012 07:20 AM, Vít Ondruch wrote:
Dne 20.2.2012 12:45, Mo Morsi napsal(a):
On 02/20/2012 04:33 AM, Vít Ondruch wrote:
Dne 13.2.2012 20:40, Mo Morsi napsal(a):
On 01/25/2012 04:46 AM, Vít Ondruch wrote:
Hi guys,
It seems that we have almost eliminated usage of RSpec 1.x:
$ repoquery --repoid=rawhide-source --arch=src --whatrequires
'rubygem(rspec)'
rubygem-ffi-0:1.0.9-2.fc16.src
rubygem-linode-0:0.6.2-1.fc15.src
$ repoquery --repoid=rawhide --whatrequires 'rubygem(rspec)'
aeolus-conductor-devel-0:0.4.0-2.fc17.noarch
$ repoquery --repoid=rawhide-source --arch=src --whatrequires
rubygem-rspec
rubygem-daemon_controller-0:0.2.6-2.fc17.src
$ repoquery --repoid=rawhide --arch=src --whatrequires rubygem-rspec
The only remaining packages are:
rubygem-ffi (bkearney) - seems to be just packaging bug:
https://bugzilla.redhat.com/show_bug.cgi?id=760009
rubygem-linode (stahnma) - upstream is already RSpec 2.x
compatible, it is FTBFS currently and it would deserve update anyway
aeolus-conductor-devel (mmorsi, clalance, sseago) - Hm, are
rubygem(rspec-rails) 2.6 compatible with RSpec 1.x? I doubt it ...
rubygem-daemon_controller (pwu) - It seems there should not be
issue running with RSpec 2.x, although I did not tested it.
Could we move forward and let the rubygem-rspec to follow the
upstream RSpec version and Require: rubygem(rspec-core)?
+1, lets move forward with this. I'm in the process of updating the
aeolus-conductor codebase to work against ruby 1.9.3 and will look
into incorporating an update to rspec 2 into this.
Since linode, ffi, and daemon_controller have been taken care of
and we've long announced the update to rspec2 in F17, lets perform
the final cutover. If there are issues going forward, we can easily
introduce a rspec1 compat package.
-Mo
Mo,
You mentioned in the packaging discussion that you have prepared
patches for rubygem-rspec to migrate them to RSpec 2.x, is that
right? Could you share them with us?
Vit
_______________________________________________
ruby-sig mailing list
[email protected]
https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
Attached. All the packages which depend on rspec 1 have been taken
care of except for rubygem-linode and aeolus-conductor (still in
progress but should be finished soon).
Patch updates the package to ruby 1.9 and removes the majority of the
contents, adding the dependencies on the
rspec-{core|mock|expectations}, bringing it inline w/ the upstream gem.
-Mo
Thank you. Unfortunately you do not solve how to migrate from BR:
rubygem(rspec-core) back to BR: rubygem(rspec). The main issue is that
rubygem-rspec-core was patched to carry rspec executable, where now it
should be moved where it belongs, i.e. into rubygem-rspec. There are
several ways:
Huh? In the upstream gem, the 'rspec' executable is provided by
rspec-core [1]. The upstream rspec gem [2] is merely a metapackage for
the three rspec subpackages (core, mock, expectations), and I'm not
seeing the aforementioned patch in the rubygem-rspec-core spec file [3]
(the 'rspec' binary is just pulled in from the upstream gem). Why would
we want to deviate from this?
1) We can let temporarily rubygem-rspec provide also the
rubygem(rspec-core), where rubygem-rspec-core would not provide any
rubygem() macro. This is ugly and against guidelines.
2) Temporarily make rubygem-rspec-core dependent on rubygem(rspec),
which is circular dependency.
Both of these workarounds would be removed for Fedora >= 18, but all
the gems which uses rubygem(rspec-core) needs to be rebuild. We can
also fake the rubygem-rspec (e.g. there would be nothing else than R:
rubygem(rspec-core), so new/updated packages could be fixed) and do it
properly for F18, including rebuild of packages.
Wouldn't it just work (tm) and be standards compliant w/ my patch as it
is? If so why don't we go w/ the simplest route for the time being and
then can massage it / tighten it up when the ruby-sig workload lightens up.
(though one thing I just realized that's missing from the patch is
explicit version requirements on the rspec subpackages, can quickly fix
that before pushing)
Also, if the test suite is executed using rspec command, we should
think if the guidelines should not recommend usage of BR:
/usr/bin/rspec instead of rubygem(rspec{,-core}). The reasoning is
that if we run the spec using rspec command, we really care just if
the rspec command is available, whoever it provides. We don't care
whether it is provided by rubygem-rspec or rubygem-rspec-core. In
contrary, if the spec suite is for some reason executed just using
ruby, e.g. "ruby spec/my_spec.rb", in this case it should be enough to
require rubygem(rspec-core) and the rspec executable would never be
installed, since it is not needed.
Sad that I did not realized this when I had done review for mtasaka.
Yeah, hard way to learn something :)
Ah ya this is a good idea. No worries, we can adjust it at somepoint
going forward.
-Mo
[1] http://rubygems.org/downloads/rspec-core-2.8.0.gem
[2] http://rubygems.org/downloads/rspec-2.8.0.gem
[3] http://pkgs.fedoraproject.org/gitweb/?p=rubygem-rspec-core.git
_______________________________________________
ruby-sig mailing list
[email protected]
https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
