----- Original Message -----
----- 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.
Yes, and the issue is at
https://github.com/rspec/rspec-core/issues/577.
--
Regards,
Bohuslav "Slavek" Kabrda.