Dne 27.2.2012 14:43, Bohuslav Kabrda napsal(a):
----- 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.
So it seems after all, that /usr/bin/rspec is not a good idea. The explanation is given in the issue from my previous email. Basically, the rspec-core gem is meant to be able to also work with different libraries than rspec-mocks and rspec-expectations. Therefore, if you install rspec, then by default you use all the rspec stuff, and if you only install rspec-core, then it is your responsibility to provide the other libraries for it.
So here is the proposed solution:
In Fedora 17, we should let the rspec-core be as it is (including the added rspec/rspec.rb file), and rspec will be completely empty and just require all the other rspec stuff.
In newer Fedoras (> 17), we should actually include the contents of rspec gem into the rpm, remove the rspec/rspec.rb from the rspec-core package and remove the dependencies on rubygem-rspec-{mocks,expectations} from rspec-core and leave them only in rspec itself. That way, from F18 we will conform with upstream completely. Also, we can use BR:rubygem(rspec) as well as R:rubygem(rspec) in F >= 17.
I'm attaching the proposed diff of the rspec specfile, that I made and I hope to get some comments from you.

Thank you for reading all this through :)



_______________________________________________
ruby-sig mailing list
ruby-sig@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/ruby-sig

So if I understand it correctly, the attached diff modifies the spec for F17 as well as for Rawhide. I like it. So if there will be no objections, I would like to go ahead with this change let say next Monday, i.e. 5th of March.

This also means that all the packages would be possible to immediately adjust to use rubygem(rspec) after this change.

Finally, the dependencies and the additional lib/rpsec.rb file would be removed from rubygem-rspec-core for F18 after F17 is declared gold, i.e. second half of May. This would leave us some time to keep focus on R1.9.3 issues before rebuild needed due the RSpec changes.


Vit