Dne 20.2.2012 13:31, Mo Morsi napsal(a):
On 02/20/2012 07:20 AM, Vít Ondruch wrote:
Dne 20.2.2012 12:45, Mo Morsi napsal(a):
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?
Ah, sorry, you are right. I was probably confused by the "lib/rspec.rb"
hack in rubygem-rspec-core which should be removed then. But in what
point in time?
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.
Now when you made me realize that I was wrong, I think it should work,
except the possible collision with the "lib/rspec.rb" mentioned above. I
need to take a look into this matter once more.
(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.
It is good time before package guidelines gets accepted I think. Anybody
against this proposal?
Vit
-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
