> ----- 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 :)
--
Regards,
Bohuslav "Slavek" Kabrda.
--- rubygem-rspec.spec 2012-02-27 13:26:02.755052525 +0100
+++ /home/bkabrda/rpmbuild/SPECS/rubygem-rspec.spec 2012-02-27 13:59:03.984247789 +0100
@@ -1,66 +1,62 @@
-%global ruby_sitelib %(ruby -rrbconfig -e "puts Config::CONFIG['sitelibdir']")
-%global gemdir %(ruby -rubygems -e 'puts Gem::dir' 2>/dev/null)
-%global gemname rspec
-%global geminstdir %{gemdir}/gems/%{gemname}-%{version}
+%global gem_name rspec
Summary: Behaviour driven development (BDD) framework for Ruby
-Name: rubygem-%{gemname}
-Version: 1.3.1
-Release: 2%{?dist}
+Name: rubygem-%{gem_name}
+Version: 2.8.0
+Release: 1%{?dist}
Group: Development/Languages
-License: GPLv2+ or Ruby
+License: MIT
URL: http://rspec.info
-Source0: http://gems.rubyforge.org/gems/%{gemname}-%{version}.gem
-Patch0: rubygem-rspec-1.3.1-RakeFileUtils_renamed_to_FileUtilsExt.patch
+%if "x%{?fedora}" != "x17"
+Source0: http://rubygems.org/downloads/%{gem_name}-%{version}.gem
+%endif
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
-Requires: rubygems, ruby(abi) = 1.8
-BuildRequires: rubygems, ruby
+Requires: rubygems
+Requires: rubygem(rspec-core) = %{version}
+Requires: rubygem(rspec-mocks) = %{version}
+Requires: rubygem(rspec-expectations) = %{version}
+Requires: ruby(abi) = 1.9.1
+BuildRequires: rubygems-devel
+BuildRequires: ruby(abi) = 1.9.1
BuildArch: noarch
-Provides: rubygem(%{gemname}) = %{version}
+Provides: rubygem(%{gem_name}) = %{version}
%description
RSpec is a behaviour driven development (BDD) framework for Ruby.
-
%prep
+%if "x%{?fedora}" != "x17"
%setup -q -c -T
-gem install \
- -V \
- --install-dir $(pwd)%{gemdir} \
- --bindir $(pwd)%{_bindir} \
- --force \
- --rdoc \
- %{SOURCE0}
-
+mkdir -p .%{gem_dir}
+gem install --local --install-dir .%{gem_dir} \
+ --force %{SOURCE0}
-pushd .%{geminstdir}
-%patch0 -p1
-popd
-
-find . -type f | xargs chmod ugo+r
+%endif
%build
%install
-mkdir -p %{buildroot}%{gemdir}
-cp -a .%{_prefix}/* %{buildroot}%{_prefix}/
-
-find %{buildroot}%{geminstdir}/bin -type f | xargs chmod a+x
-
-%clean
+%if "x%{?fedora}" != "x17"
rm -rf %{buildroot}
+mkdir -p %{buildroot}%{gem_dir}
+cp -a .%{gem_dir}/* %{buildroot}%{gem_dir}
+%endif
%files
-%defattr(-, root, root, -)
-%{_bindir}/*
-%{gemdir}/gems/%{gemname}-%{version}/
-%doc %{gemdir}/doc/%{gemname}-%{version}
-#%doc %{geminstdir}/*.txt
-%{gemdir}/cache/%{gemname}-%{version}.gem
-%{gemdir}/specifications/%{gemname}-%{version}.gemspec
-
+%if "x%{?fedora}" != "x17"
+%doc %{gem_docdir}
+%dir %{gem_instdir}
+%{gem_instdir}/lib
+%{gem_instdir}/License.txt
+%{gem_instdir}/README.markdown
+%{gem_cache}
+%{gem_spec}
+%endif
%changelog
+* Mon Feb 27 2012 Bohuslav Kabrda <[email protected]> - 2.8.0-1
+- Rebuilt for F17 (no content for F17, rspec/rspec.rb is located in rubygem-rspec-core).
+
* Sat Jan 14 2012 Fedora Release Engineering <[email protected]> - 1.3.1-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_17_Mass_Rebuild
_______________________________________________
ruby-sig mailing list
[email protected]
https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
