----- Original Message -----
----- 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.
So here is my resume :) :
The /usr/bin/rspec dependency can be used most of the time, as the rspec-core gem (that
contains it) draws all the dependencies (rspec-mocks, rspec-expectations) in by itself.
The only thing that it doesn't contain is the rspec/rspec.rb file, which is currently
created in our specfile. So, with the upstream version, everything works fine if the specs
don't "require 'rspec'". I'm really not sure why there have to
be rspec and rspec-core gems, since the rspec gem doesn't really do anything. I asked
upstream, so let's wait what they'll respond.
As a result, it is not always possible to rely on /usr/bin/rspec without having it
modified the way we do.
--
Regards,
Bohuslav "Slavek" Kabrda.