----- Original Message -----
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
I agree that BR:/usr/bin/rspec is right - and it will also draw in only the necessary
dependencies. As for the runtime Requires, I believe we should stick with what's
written in the gemspec (if it is rspec, let it be rspec, if rspec-core, then rspec-core).
This way, we can make sure that requiring gem doesn't break with "Could not find
rspec (= 2.8) amongst [...]" - that should probably be mentioned in the guidelines
too, so that someone doesn't do Requires: /usr/bin/rspec.
And yes, we should make an explicit note to the guidelines, that BR:/usr/bin/rspec is the
right way to do things before they get approved (and then slowly change this when updating
the packages that depend on rubygem(rspec-core)).
--
Regards,
Bohuslav "Slavek" Kabrda.