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