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