Migration from RSpec 1.3 to RSpec 2.x

[Vít Ondruch]

Hi guys,

Since February, there are available RSpec 2.x in Fedora repositories. 
However, as of now, the main package rubygem-rspec was not migrated to 
RSpec 2.x and still provides RSpec 1.3 functionality. It would be nice, 
if we could finish the migration to RSpec 2.x lets say in F17 time 
frame. What are your opinions? The list of packages which depends on 
RSpec 1.3 is attached bellow.

If you wonder how to use RSpec 2.x for your package, it is usually quite 
easy. In you spec just replace

BuildRequires: rubygem(rspec)

with

# Use rspec-core until rspec are migrated to RSpec 2.x
BuildRequires: rubygem(rspec-core)

and in you %check section, if you are not using Rake, replace call to 
'spec' with 'rspec'. As an example, you can take a look on one of mine 
rubygems, e.g. rubygem-regin, rubygem-pg.

Once we will migrate all packages into RSpec 2.x, we can migrate also 
the rubygem-rspec and change the BR back to rubygem(rspec).


Vit


-------- Pu*vodní zpráva --------
Pr(edme(t: 	Re: aeolus conductor / rails 3 / F16 integration path
Datum: 	Tue, 12 Jul 2011 10:47:36 -0400
Od: 	Mo Morsi <mmorsi(a)redhat.com&gt;
Komu: 	Vít Ondruch <vondruch(a)redhat.com&gt;



>   It is currently 24 packages which are using RSpec 1.x:
>
>   ]$ repoquery --repoid=fedora-source --arch=src --whatrequires
>   'rubygem(rspec)'
>   rubygem-bcrypt-ruby-0:2.1.2-2.fc15.src    (mmorsi)
>   rubygem-boxgrinder-build-0:0.9.1-1.fc15.src  (goldmann)
>   rubygem-boxgrinder-core-0:0.3.1-1.fc15.src (goldmann)
>   rubygem-commander-0:4.0.3-4.fc15.src  (mfojtik)
>   rubygem-cucumber-0:0.10.0-5.fc15.src  (mmorsi, clalance, mfojtik)
>   rubygem-cucumber-rails-0:0.3.2-5.fc15.src  (mmorsi, clalance, mfojtik)
>   rubygem-facon-0:0.4.1-2.fc15.src    (stahnma)
>   rubygem-factory_girl-0:1.3.2-3.fc15.src    (mfojtik)
>   rubygem-ffi-0:0.6.3-2.fc15.src   (bkearney)
>   rubygem-linode-0:0.6.2-1.fc15.src   (stahnma)
>   rubygem-mail-0:2.2.15-2.fc15.src - upstream at 1.3.x   (vondruch)
>   rubygem-multimap-0:1.1.2-3.fc15.src - upstream at 1.3.x  (mmorsi)
>   rubygem-mustache-0:0.11.2-5.fc15.src - doesn't use RSpec at all. Seems to be wrong
> dependency    (vondruch)
>   rubygem-rack-test-0:0.5.4-1.fc15.src    (mfojtik)
>   rubygem-rake-compiler-0:0.7.8-1.fc15.src    (mamoru)
>   rubygem-regin-0:0.3.7-3.fc15.src - upstream at 2.x   (vondruch)
>   rubygem-rerun-0:0.5.2-4.fc15.src     (mfojtik)
>   rubygem-scruffy-0:0.2.6-2.fc15.src   (mmorsi)
>   rubygem-simple-navigation-0:3.0.0-3.fc15.src   (mfojtik)
>   rubygem-thin-0:1.2.7-2.fc15.src   (mfojtik)
>   rubygem-typhoeus-0:0.2.0-2.fc15.src  (mfojtik)
>   rubygem-uuidtools-0:2.1.1-1.fc14.src  (mmorsi)
>   rubygem-warden-0:1.0.3-4.fc15.src - upstream at 2.x  (vondruch)
>   rubygem-yard-0:0.5.3-3.fc14.src  (mmorsi)
>
>   So from my packages, 2 can be converted into RSpec 2.x right now, 2 are
>   using 1.3, so it would need some effort and 1 seems to be just wrong
>   dependency. May be we should move this discussion into ruby-sig ML 

I appended the package owners onto the list for future reference.

Agree on moving this conversation to ruby-sig.

[Marek Goldmann]

Vit,

Thanks for heads-up, I moved rubygem-boxgrinder* packages upstream to RSpec2. Next
releases will include the change.

--Marek

On 2011-07-13, at 08:53, Vít Ondruch wrote:

>  Hi guys,
>  
>  Since February, there are available RSpec 2.x in Fedora repositories. However, as of now,
> the main package rubygem-rspec was not migrated to RSpec 2.x and still provides RSpec 1.3
> functionality. It would be nice, if we could finish the migration to RSpec 2.x lets say in
> F17 time frame. What are your opinions? The list of packages which depends on RSpec 1.3 is
> attached bellow.
>  
>  If you wonder how to use RSpec 2.x for your package, it is usually quite easy. In you
> spec just replace
>  
>  BuildRequires: rubygem(rspec)
>  
>  with
>  
>  # Use rspec-core until rspec are migrated to RSpec 2.x
>  BuildRequires: rubygem(rspec-core)
>  
>  and in you %check section, if you are not using Rake, replace call to 'spec' with
> 'rspec'. As an example, you can take a look on one of mine rubygems, e.g.
> rubygem-regin, rubygem-pg.
>  
>  Once we will migrate all packages into RSpec 2.x, we can migrate also the rubygem-rspec
> and change the BR back to rubygem(rspec).
>  
>  
>  Vit
>  
>  
>  -------- Původní zpráva --------
>  Předmět:	Re: aeolus conductor / rails 3 / F16 integration path
>  Datum:	Tue, 12 Jul 2011 10:47:36 -0400
>  Od:	Mo Morsi <mmorsi(a)redhat.com&gt;
>  Komu:	Vít Ondruch <vondruch(a)redhat.com&gt;
>  
>  > It is currently 24 packages which are using RSpec 1.x:
>  > 
>  > ]$ repoquery --repoid=fedora-source --arch=src --whatrequires
>  > 'rubygem(rspec)'
>  > rubygem-bcrypt-ruby-0:2.1.2-2.fc15.src    (mmorsi)
>  > rubygem-boxgrinder-build-0:0.9.1-1.fc15.src  (goldmann)
>  > rubygem-boxgrinder-core-0:0.3.1-1.fc15.src (goldmann)
>  > rubygem-commander-0:4.0.3-4.fc15.src  (mfojtik)
>  > rubygem-cucumber-0:0.10.0-5.fc15.src  (mmorsi, clalance, mfojtik)
>  > rubygem-cucumber-rails-0:0.3.2-5.fc15.src  (mmorsi, clalance, mfojtik)
>  > rubygem-facon-0:0.4.1-2.fc15.src    (stahnma)
>  > rubygem-factory_girl-0:1.3.2-3.fc15.src    (mfojtik)
>  > rubygem-ffi-0:0.6.3-2.fc15.src   (bkearney)
>  > rubygem-linode-0:0.6.2-1.fc15.src   (stahnma)
>  > rubygem-mail-0:2.2.15-2.fc15.src - upstream at 1.3.x   (vondruch)
>  > rubygem-multimap-0:1.1.2-3.fc15.src - upstream at 1.3.x  (mmorsi)
>  > rubygem-mustache-0:0.11.2-5.fc15.src - doesn't use RSpec at all. Seems to be
> wrong dependency    (vondruch)
>  > rubygem-rack-test-0:0.5.4-1.fc15.src    (mfojtik)
>  > rubygem-rake-compiler-0:0.7.8-1.fc15.src    (mamoru)
>  > rubygem-regin-0:0.3.7-3.fc15.src - upstream at 2.x   (vondruch)
>  > rubygem-rerun-0:0.5.2-4.fc15.src     (mfojtik)
>  > rubygem-scruffy-0:0.2.6-2.fc15.src   (mmorsi)
>  > rubygem-simple-navigation-0:3.0.0-3.fc15.src   (mfojtik)
>  > rubygem-thin-0:1.2.7-2.fc15.src   (mfojtik)
>  > rubygem-typhoeus-0:0.2.0-2.fc15.src  (mfojtik)
>  > rubygem-uuidtools-0:2.1.1-1.fc14.src  (mmorsi)
>  > rubygem-warden-0:1.0.3-4.fc15.src - upstream at 2.x  (vondruch)
>  > rubygem-yard-0:0.5.3-3.fc14.src  (mmorsi)
>  > 
>  > So from my packages, 2 can be converted into RSpec 2.x right now, 2 are
>  > using 1.3, so it would need some effort and 1 seems to be just wrong
>  > dependency. May be we should move this discussion into ruby-sig ML
>  
>  
>  I appended the package owners onto the list for future reference.
>  
>  Agree on moving this conversation to ruby-sig.
>  
>  
>  _______________________________________________
>  ruby-sig mailing list
>  ruby-sig(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/ruby-sig

[Mo Morsi]

On 07/13/2011 02:53 AM, Vít Ondruch wrote:
>  Hi guys,
>  
>  Since February, there are available RSpec 2.x in Fedora repositories.
>  However, as of now, the main package rubygem-rspec was not migrated to
>  RSpec 2.x and still provides RSpec 1.3 functionality. It would be nice,
>  if we could finish the migration to RSpec 2.x lets say in F17 time
>  frame. What are your opinions? The list of packages which depends on
>  RSpec 1.3 is attached bellow.
>   
IMO F17 seems like a reasonable timeline for this. At that point we
might also want to provide a rubygem-rspec1-compat package for any gems
whose upstream communities haven't switched over.

  -Mo

[Tyler Smart]

Just a question, but who all is using Rspec 1.3.3 like me? I work on the rhsm-web team in
Raleigh and have implemented all my tests with rspec 1.3.3. Is anyone else already on
2.x?

========= 
Tyler Smart 
Check out the IT.rb group: 
https://docspace.corp.redhat.com/groups/itrb 

----- Original Message -----
From: "Mo Morsi" <mmorsi(a)redhat.com&gt;
To: ruby-sig(a)lists.fedoraproject.org
Sent: Thursday, July 14, 2011 10:15:22 PM
Subject: Re: Migration from RSpec 1.3 to RSpec 2.x

On 07/13/2011 02:53 AM, Vít Ondruch wrote:
>  Hi guys,
>  
>  Since February, there are available RSpec 2.x in Fedora repositories.
>  However, as of now, the main package rubygem-rspec was not migrated to
>  RSpec 2.x and still provides RSpec 1.3 functionality. It would be nice,
>  if we could finish the migration to RSpec 2.x lets say in F17 time
>  frame. What are your opinions? The list of packages which depends on
>  RSpec 1.3 is attached bellow.
>   
IMO F17 seems like a reasonable timeline for this. At that point we
might also want to provide a rubygem-rspec1-compat package for any gems
whose upstream communities haven't switched over.

  -Mo
_______________________________________________
ruby-sig mailing list
ruby-sig(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/ruby-sig

[Marek Goldmann]

Tyler,

Depending on your code - migration can be pretty easy. It took me about 5 minutes for
example:

	https://github.com/boxgrinder/boxgrinder-build/commit/bbd2083d4cf25d31cb7...

So I highly recommend doing that earlier than later :)

--Marek

On 2011-07-15, at 14:09, Tyler Smart wrote:

>  Just a question, but who all is using Rspec 1.3.3 like me? I work on
> the rhsm-web team in Raleigh and have implemented all my tests with rspec 1.3.3. Is anyone
> else already on 2.x?

[Vít Ondruch]

The most differences are usually in spec_helper.rb if you are using one, 
otherwise there are usually no issues.

Vit



Dne 15.7.2011 14:19, Marek Goldmann napsal(a):
>  Tyler,
>
>  Depending on your code - migration can be pretty easy. It took me about 5 minutes for
> example:
>
>
> 	https://github.com/boxgrinder/boxgrinder-build/commit/bbd2083d4cf25d31cb7...
>
>  So I highly recommend doing that earlier than later :)
>
>  --Marek
>
>  On 2011-07-15, at 14:09, Tyler Smart wrote:
>
> > Just a question, but who all is using Rspec 1.3.3 like me? I work on the rhsm-web
> team in Raleigh and have implemented all my tests with rspec 1.3.3. Is anyone else already
> on 2.x?
>  _______________________________________________
>  ruby-sig mailing list
>  ruby-sig(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/ruby-sig

[Tyler Smart]

I have to migrate to Rails 3 for that, right :) One step at a time.

========= 
Tyler Smart 
Check out the IT.rb group: 
https://docspace.corp.redhat.com/groups/itrb 

----- Original Message -----
From: "Vít Ondruch" <vondruch(a)redhat.com&gt;
To: ruby-sig(a)lists.fedoraproject.org
Sent: Friday, July 15, 2011 8:36:08 AM
Subject: Re: Migration from RSpec 1.3 to RSpec 2.x

The most differences are usually in spec_helper.rb if you are using one, 
otherwise there are usually no issues.

Vit



Dne 15.7.2011 14:19, Marek Goldmann napsal(a):
>  Tyler,
>
>  Depending on your code - migration can be pretty easy. It took me about 5 minutes for
> example:
>
>
> 	https://github.com/boxgrinder/boxgrinder-build/commit/bbd2083d4cf25d31cb7...
>
>  So I highly recommend doing that earlier than later :)
>
>  --Marek
>
>  On 2011-07-15, at 14:09, Tyler Smart wrote:
>
> > Just a question, but who all is using Rspec 1.3.3 like me? I work on the rhsm-web
> team in Raleigh and have implemented all my tests with rspec 1.3.3. Is anyone else already
> on 2.x?
>  _______________________________________________
>  ruby-sig mailing list
>  ruby-sig(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/ruby-sig 
_______________________________________________
ruby-sig mailing list
ruby-sig(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/ruby-sig

[Vít Ondruch]

spec_helper.rb doesn't have necessarily anything to do with Rails, 
although Rails can use such file.

Vit



Dne 15.7.2011 14:45, Tyler Smart napsal(a):
>  I have to migrate to Rails 3 for that, right :) One step at a time.
>
>  =========
>  Tyler Smart
>  Check out the IT.rb group:
>  https://docspace.corp.redhat.com/groups/itrb
>
>  ----- Original Message -----
>  From: "Vít Ondruch"<vondruch(a)redhat.com>
>  To: ruby-sig(a)lists.fedoraproject.org
>  Sent: Friday, July 15, 2011 8:36:08 AM
>  Subject: Re: Migration from RSpec 1.3 to RSpec 2.x
>
>  The most differences are usually in spec_helper.rb if you are using one,
>  otherwise there are usually no issues.
>
>  Vit
>
>
>
>  Dne 15.7.2011 14:19, Marek Goldmann napsal(a):
> > Tyler,
> >
> > Depending on your code - migration can be pretty easy. It took me about 5 minutes for
> example:
> >
> >
> 	https://github.com/boxgrinder/boxgrinder-build/commit/bbd2083d4cf25d31cb7...
> >
> > So I highly recommend doing that earlier than later :)
> >
> > --Marek
> >
> > On 2011-07-15, at 14:09, Tyler Smart wrote:
> >
> >> Just a question, but who all is using Rspec 1.3.3 like me? I work on the rhsm-web
> team in Raleigh and have implemented all my tests with rspec 1.3.3. Is anyone else already
> on 2.x?
> > _______________________________________________
> > ruby-sig mailing list
> > ruby-sig(a)lists.fedoraproject.org
> > https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
>  _______________________________________________
>  ruby-sig mailing list
>  ruby-sig(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
>  _______________________________________________
>  ruby-sig mailing list
>  ruby-sig(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/ruby-sig

[Mamoru TASAKA]

Mo Morsi wrote, at 07/15/2011 11:15 AM +9:00:
>  On 07/13/2011 02:53 AM, Vít Ondruch wrote:
> > Hi guys,
> >
> > Since February, there are available RSpec 2.x in Fedora repositories.
> > However, as of now, the main package rubygem-rspec was not migrated to
> > RSpec 2.x and still provides RSpec 1.3 functionality. It would be nice,
> > if we could finish the migration to RSpec 2.x lets say in F17 time
> > frame. What are your opinions? The list of packages which depends on
> > RSpec 1.3 is attached bellow.
> >
>
>  IMO F17 seems like a reasonable timeline for this. At that point we
>  might also want to provide a rubygem-rspec1-compat package for any gems
>  whose upstream communities haven't switched over.
>  
Can't we do this (i.e. rspec 2 by default, rspec 1 move to compat mode)
before F-16/17 branch (i.e. 2011-07-26)?

I prepared rubygem-rspec-2.6.0 and rubygem-"rspec1"-1.3.2:
http://mtasaka.fedorapeople.org/Trial-rpms/rubygem-rspec-2.6.0-1.fc.src.rpm
http://mtasaka.fedorapeople.org/Trial-rpms/rubygem-rspec1-1.3.2-2.fc.src.rpm
http://mtasaka.fedorapeople.org/Trial-rpms/rubygem-rspec.spec
http://mtasaka.fedorapeople.org/Trial-rpms/rubygem-rspec1.spec

With these rpms,
- people who wants to use rspec 1 has to specify it as
   (Build)Requires: rubygem(rspec1), rubygem(rspec), and to use
   "gem 'rspec1'", not "gem 'rspec'". /usr/bin/spec
remains as before.
- people who want to use rspec 2 will specify it as
   (Build)Requires: rubygem(rspec), and "gem 'rspec'". Note that
   /usr/bin/rspec is (already) in rubygem-rspec-core-2.6.4.

If we can agree with these changes, I will submit these specs/srpms for
review requests.

Regards,
Mamoru

[Michael Stahnke]

On Sun, Jul 17, 2011 at 4:42 PM, TASAKA Mamoru
<mtasaka(a)fedoraproject.org&gt; wrote:
>  Mo Morsi wrote, at 07/15/2011 11:15 AM +9:00:
> > On 07/13/2011 02:53 AM, Vít Ondruch wrote:
> >> Hi guys,
> >>
> >> Since February, there are available RSpec 2.x in Fedora repositories.
> >> However, as of now, the main package rubygem-rspec was not migrated to
> >> RSpec 2.x and still provides RSpec 1.3 functionality. It would be nice,
> >> if we could finish the migration to RSpec 2.x lets say in F17 time
> >> frame. What are your opinions? The list of packages which depends on
> >> RSpec 1.3 is attached bellow.
> >>
> >
> > IMO F17 seems like a reasonable timeline for this. At that point we
> > might also want to provide a rubygem-rspec1-compat package for any gems
> > whose upstream communities haven't switched over.
> >
>
>  Can't we do this (i.e. rspec 2 by default, rspec 1 move to compat mode)
>  before F-16/17 branch (i.e. 2011-07-26)?
>
>  I prepared rubygem-rspec-2.6.0 and rubygem-"rspec1"-1.3.2:
>  http://mtasaka.fedorapeople.org/Trial-rpms/rubygem-rspec-2.6.0-1.fc.src.rpm
>  http://mtasaka.fedorapeople.org/Trial-rpms/rubygem-rspec1-1.3.2-2.fc.src.rpm
>  http://mtasaka.fedorapeople.org/Trial-rpms/rubygem-rspec.spec
>  http://mtasaka.fedorapeople.org/Trial-rpms/rubygem-rspec1.spec
>
>  With these rpms,
>  - people who wants to use rspec 1 has to specify it as
>    (Build)Requires: rubygem(rspec1), rubygem(rspec), and to use
>    "gem 'rspec1'", not "gem 'rspec'". /usr/bin/spec
> remains as before.
>  - people who want to use rspec 2 will specify it as
>    (Build)Requires: rubygem(rspec), and "gem 'rspec'". Note that
>    /usr/bin/rspec is (already) in rubygem-rspec-core-2.6.4.
>
>  If we can agree with these changes, I will submit these specs/srpms for
>  review requests.
>  
I assume that would cause rspec to be dead.packaged.  I am ok with that too.

stahnma

>  Regards,
>  Mamoru
>
>
>  _______________________________________________
>  ruby-sig mailing list
>  ruby-sig(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/ruby-sig

[Vít Ondruch]

Dne 18.7.2011 03:05, Michael Stahnke napsal(a):
>  On Sun, Jul 17, 2011 at 4:42 PM, TASAKA Mamoru
>  <mtasaka(a)fedoraproject.org&gt;  wrote:
> > Mo Morsi wrote, at 07/15/2011 11:15 AM +9:00:
> >> On 07/13/2011 02:53 AM, Vít Ondruch wrote:
> >>> Hi guys,
> >>>
> >>> Since February, there are available RSpec 2.x in Fedora repositories.
> >>> However, as of now, the main package rubygem-rspec was not migrated to
> >>> RSpec 2.x and still provides RSpec 1.3 functionality. It would be nice,
> >>> if we could finish the migration to RSpec 2.x lets say in F17 time
> >>> frame. What are your opinions? The list of packages which depends on
> >>> RSpec 1.3 is attached bellow.
> >>>
> >> IMO F17 seems like a reasonable timeline for this. At that point we
> >> might also want to provide a rubygem-rspec1-compat package for any gems
> >> whose upstream communities haven't switched over.
> >>
> > Can't we do this (i.e. rspec 2 by default, rspec 1 move to compat mode)
> > before F-16/17 branch (i.e. 2011-07-26)?
> >
> > I prepared rubygem-rspec-2.6.0 and rubygem-"rspec1"-1.3.2:
> > http://mtasaka.fedorapeople.org/Trial-rpms/rubygem-rspec-2.6.0-1.fc.src.rpm
> > http://mtasaka.fedorapeople.org/Trial-rpms/rubygem-rspec1-1.3.2-2.fc.src.rpm
> > http://mtasaka.fedorapeople.org/Trial-rpms/rubygem-rspec.spec
> > http://mtasaka.fedorapeople.org/Trial-rpms/rubygem-rspec1.spec
> >
> > With these rpms,
> > - people who wants to use rspec 1 has to specify it as
> >    (Build)Requires: rubygem(rspec1), rubygem(rspec), and to use
> >    "gem 'rspec1'", not "gem 'rspec'".
> /usr/bin/spec remains as before.
> > - people who want to use rspec 2 will specify it as
> >    (Build)Requires: rubygem(rspec), and "gem 'rspec'". Note that
> >    /usr/bin/rspec is (already) in rubygem-rspec-core-2.6.4.
> >
> > If we can agree with these changes, I will submit these specs/srpms for
> > review requests.
> >
>  I assume that would cause rspec to be dead.packaged.  I am ok with that too. 
I don't think so. rubygem-rspec will provide rspec 2.x metapackage. See 
attached Mamoru's spec.

>  stahnma
>
> > Regards,
> > Mamoru
> >
> >
> > _______________________________________________
> > ruby-sig mailing list
> > ruby-sig(a)lists.fedoraproject.org
> > https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
>  _______________________________________________
>  ruby-sig mailing list
>  ruby-sig(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/ruby-sig

[Vít Ondruch]

Dne 18.7.2011 01:42, TASAKA Mamoru napsal(a):
>  Mo Morsi wrote, at 07/15/2011 11:15 AM +9:00:
> > On 07/13/2011 02:53 AM, Vít Ondruch wrote:
> >> Hi guys,
> >>
> >> Since February, there are available RSpec 2.x in Fedora repositories.
> >> However, as of now, the main package rubygem-rspec was not migrated to
> >> RSpec 2.x and still provides RSpec 1.3 functionality. It would be nice,
> >> if we could finish the migration to RSpec 2.x lets say in F17 time
> >> frame. What are your opinions? The list of packages which depends on
> >> RSpec 1.3 is attached bellow.
> >>
> > IMO F17 seems like a reasonable timeline for this. At that point we
> > might also want to provide a rubygem-rspec1-compat package for any gems
> > whose upstream communities haven't switched over.
> >
>  Can't we do this (i.e. rspec 2 by default, rspec 1 move to compat mode)
>  before F-16/17 branch (i.e. 2011-07-26)? 
Is it worth of it? We can push the change right now, but it will make 
some packages FTBFS. Don't take me wrong, I personally +1 for this 
change, I just wanted to give a chance to others to be prepared.

>  I prepared rubygem-rspec-2.6.0 and rubygem-"rspec1"-1.3.2:
>  http://mtasaka.fedorapeople.org/Trial-rpms/rubygem-rspec-2.6.0-1.fc.src.rpm
>  http://mtasaka.fedorapeople.org/Trial-rpms/rubygem-rspec1-1.3.2-2.fc.src.rpm
>  http://mtasaka.fedorapeople.org/Trial-rpms/rubygem-rspec.spec
>  http://mtasaka.fedorapeople.org/Trial-rpms/rubygem-rspec1.spec 
Is the change in folder structure, i.e. rename from rspec to rspec1 
really necessary? The gems don't conflicts, so it seems to me too much 
effort for no benefit.

>  With these rpms,
>  - people who wants to use rspec 1 has to specify it as
>      (Build)Requires: rubygem(rspec1), rubygem(rspec), and to use
>      "gem 'rspec1'", not "gem 'rspec'". /usr/bin/spec
> remains as before.
>  - people who want to use rspec 2 will specify it as
>      (Build)Requires: rubygem(rspec), and "gem 'rspec'". Note that
>      /usr/bin/rspec is (already) in rubygem-rspec-core-2.6.4.
>
>  If we can agree with these changes, I will submit these specs/srpms for
>  review requests.
>
>  Regards,
>  Mamoru
>
>
>  _______________________________________________
>  ruby-sig mailing list
>  ruby-sig(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/ruby-sig

[Mamoru TASAKA]

Vít Ondruch wrote, at 07/18/2011 04:37 PM +9:00:
>  Dne 18.7.2011 01:42, TASAKA Mamoru napsal(a):
> > Mo Morsi wrote, at 07/15/2011 11:15 AM +9:00:
> >> On 07/13/2011 02:53 AM, Vít Ondruch wrote:
> >>> Hi guys,
> >>>
> >>> Since February, there are available RSpec 2.x in Fedora repositories.
> >>> However, as of now, the main package rubygem-rspec was not migrated to
> >>> RSpec 2.x and still provides RSpec 1.3 functionality. It would be nice,
> >>> if we could finish the migration to RSpec 2.x lets say in F17 time
> >>> frame. What are your opinions? The list of packages which depends on
> >>> RSpec 1.3 is attached bellow.
> >>>
> >> IMO F17 seems like a reasonable timeline for this. At that point we
> >> might also want to provide a rubygem-rspec1-compat package for any gems
> >> whose upstream communities haven't switched over.
> >>
> > Can't we do this (i.e. rspec 2 by default, rspec 1 move to compat mode)
> > before F-16/17 branch (i.e. 2011-07-26)?
>
>  Is it worth of it? We can push the change right now, but it will make
>  some packages FTBFS. Don't take me wrong, I personally +1 for this
>  change, I just wanted to give a chance to others to be prepared. 
With rubygem-rspec1 imported, I will change all packages which currently
have "BR: rubygem(rspec)" to "BR: rubygem(rspec1)" and rebuild all
those srpms.
If those srpm don't have FTBFS issue right now, they should also succeed on
building after this change (if they fail to build after this change, I guess
they already had FTBFS issue)

> > I prepared rubygem-rspec-2.6.0 and rubygem-"rspec1"-1.3.2:
> > http://mtasaka.fedorapeople.org/Trial-rpms/rubygem-rspec-2.6.0-1.fc.src.rpm
> > http://mtasaka.fedorapeople.org/Trial-rpms/rubygem-rspec1-1.3.2-2.fc.src.rpm
> > http://mtasaka.fedorapeople.org/Trial-rpms/rubygem-rspec.spec
> > http://mtasaka.fedorapeople.org/Trial-rpms/rubygem-rspec1.spec
>
>  Is the change in folder structure, i.e. rename from rspec to rspec1
>  really necessary? The gems don't conflicts, so it seems to me too much
>  effort for no benefit. 
Well,
- We cannot have two "rubygem-rspec" srpm (on Fedora repository), so anyway
   one of these should be renamed on srpm name level. With srpm renamed to
   "rubygem-rspec1", I think reconstructuring directories and especially
   changing rspec-1.X.gemspec to rspec"1"-1.X.gemspec would be less confusing
   as it "matches" currently rubygem based rpms' structure
- Anyway I think we can agree with any of the ways.

> > With these rpms,
> > - people who wants to use rspec 1 has to specify it as
> >      (Build)Requires: rubygem(rspec1), rubygem(rspec), and to use
> >      "gem 'rspec1'", not "gem 'rspec'".
> /usr/bin/spec remains as before.
> > - people who want to use rspec 2 will specify it as
> >      (Build)Requires: rubygem(rspec), and "gem 'rspec'". Note that
> >      /usr/bin/rspec is (already) in rubygem-rspec-core-2.6.4.
> >
> > If we can agree with these changes, I will submit these specs/srpms for
> > review requests. 
Regards,
Mamoru

[Vít Ondruch]

rubygem-rspec1 package is of course one possibility, but I would be 
happier if we never introduce such package. This package would be 
introduced only for backward compatibility and people (developers) would 
be never motivated to move forward. This is against one of Fedora Fs 
(First).

The biggest problem with rubygem-rspec1 is that is has not defined its 
lifespan and even if it has, there always be somebody requesting some 
compatibility packages for whatever reason. I just tried to propose to 
deprecate RSpec 1 for F17.

The time which would be spent on reviewing/maintaining the RSpec 1.x 
package would be better spent by ensuring that all packages work with 
RSpec 2.x and submitting patches upstream if necessary.


Vit



Dne 18.7.2011 09:59, TASAKA Mamoru napsal(a):
>  Vít Ondruch wrote, at 07/18/2011 04:37 PM +9:00:
> > Dne 18.7.2011 01:42, TASAKA Mamoru napsal(a):
> >> Mo Morsi wrote, at 07/15/2011 11:15 AM +9:00:
> >>> On 07/13/2011 02:53 AM, Vít Ondruch wrote:
> >>>> Hi guys,
> >>>>
> >>>> Since February, there are available RSpec 2.x in Fedora repositories.
> >>>> However, as of now, the main package rubygem-rspec was not migrated to
> >>>> RSpec 2.x and still provides RSpec 1.3 functionality. It would be nice,
> >>>> if we could finish the migration to RSpec 2.x lets say in F17 time
> >>>> frame. What are your opinions? The list of packages which depends on
> >>>> RSpec 1.3 is attached bellow.
> >>>>
> >>> IMO F17 seems like a reasonable timeline for this. At that point we
> >>> might also want to provide a rubygem-rspec1-compat package for any gems
> >>> whose upstream communities haven't switched over.
> >>>
> >> Can't we do this (i.e. rspec 2 by default, rspec 1 move to compat mode)
> >> before F-16/17 branch (i.e. 2011-07-26)?
> > Is it worth of it? We can push the change right now, but it will make
> > some packages FTBFS. Don't take me wrong, I personally +1 for this
> > change, I just wanted to give a chance to others to be prepared.
>  With rubygem-rspec1 imported, I will change all packages which currently
>  have "BR: rubygem(rspec)" to "BR: rubygem(rspec1)" and rebuild all
> those srpms.
>  If those srpm don't have FTBFS issue right now, they should also succeed on
>  building after this change (if they fail to build after this change, I guess
>  they already had FTBFS issue)
>
> >> I prepared rubygem-rspec-2.6.0 and rubygem-"rspec1"-1.3.2:
> >> http://mtasaka.fedorapeople.org/Trial-rpms/rubygem-rspec-2.6.0-1.fc.src.rpm
> >> http://mtasaka.fedorapeople.org/Trial-rpms/rubygem-rspec1-1.3.2-2.fc.src.rpm
> >> http://mtasaka.fedorapeople.org/Trial-rpms/rubygem-rspec.spec
> >> http://mtasaka.fedorapeople.org/Trial-rpms/rubygem-rspec1.spec
> > Is the change in folder structure, i.e. rename from rspec to rspec1
> > really necessary? The gems don't conflicts, so it seems to me too much
> > effort for no benefit.
>  Well,
>  - We cannot have two "rubygem-rspec" srpm (on Fedora repository), so anyway
>      one of these should be renamed on srpm name level. With srpm renamed to
>      "rubygem-rspec1", I think reconstructuring directories and especially
>      changing rspec-1.X.gemspec to rspec"1"-1.X.gemspec would be less confusing
>      as it "matches" currently rubygem based rpms' structure
>  - Anyway I think we can agree with any of the ways.
>
> >> With these rpms,
> >> - people who wants to use rspec 1 has to specify it as
> >>       (Build)Requires: rubygem(rspec1), rubygem(rspec), and to use
> >>       "gem 'rspec1'", not "gem 'rspec'".
> /usr/bin/spec remains as before.
> >> - people who want to use rspec 2 will specify it as
> >>       (Build)Requires: rubygem(rspec), and "gem 'rspec'". Note
> that
> >>       /usr/bin/rspec is (already) in rubygem-rspec-core-2.6.4.
> >>
> >> If we can agree with these changes, I will submit these specs/srpms for
> >> review requests.
>  Regards,
>  Mamoru
>
>
>  _______________________________________________
>  ruby-sig mailing list
>  ruby-sig(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/ruby-sig

[Mo Morsi]

Perhaps we can shoot for doing this w/ F17, and if we are unable to
migrate all the dependent packages over, then add a rspec1 compat
package to buy us some more time.

In any case, would rather push this off to F17 myself as a few of us are
going through and updating alot of the rails related plugins to be
compatible w/ Rails 3 in Fedora. We're trying to get this done by the
F16 deadline next week.

  -Mo

On 07/18/2011 04:44 AM, Vít Ondruch wrote:
>  rubygem-rspec1 package is of course one possibility, but I would be 
>  happier if we never introduce such package. This package would be 
>  introduced only for backward compatibility and people (developers) would 
>  be never motivated to move forward. This is against one of Fedora Fs 
>  (First).
>  
>  The biggest problem with rubygem-rspec1 is that is has not defined its 
>  lifespan and even if it has, there always be somebody requesting some 
>  compatibility packages for whatever reason. I just tried to propose to 
>  deprecate RSpec 1 for F17.
>  
>  The time which would be spent on reviewing/maintaining the RSpec 1.x 
>  package would be better spent by ensuring that all packages work with 
>  RSpec 2.x and submitting patches upstream if necessary.
>  
>  
>  Vit
>  
>  
>  
>  Dne 18.7.2011 09:59, TASAKA Mamoru napsal(a):
> > Vít Ondruch wrote, at 07/18/2011 04:37 PM +9:00:
> >> Dne 18.7.2011 01:42, TASAKA Mamoru napsal(a):
> >>> Mo Morsi wrote, at 07/15/2011 11:15 AM +9:00:
> >>>> On 07/13/2011 02:53 AM, Vít Ondruch wrote:
> >>>>> Hi guys,
> >>>>>
> >>>>> Since February, there are available RSpec 2.x in Fedora
> repositories.
> >>>>> However, as of now, the main package rubygem-rspec was not migrated
> to
> >>>>> RSpec 2.x and still provides RSpec 1.3 functionality. It would be
> nice,
> >>>>> if we could finish the migration to RSpec 2.x lets say in F17 time
> >>>>> frame. What are your opinions? The list of packages which depends on
> >>>>> RSpec 1.3 is attached bellow.
> >>>>>
> >>>> IMO F17 seems like a reasonable timeline for this. At that point we
> >>>> might also want to provide a rubygem-rspec1-compat package for any gems
> >>>> whose upstream communities haven't switched over.
> >>>>
> >>> Can't we do this (i.e. rspec 2 by default, rspec 1 move to compat mode)
> >>> before F-16/17 branch (i.e. 2011-07-26)?
> >> Is it worth of it? We can push the change right now, but it will make
> >> some packages FTBFS. Don't take me wrong, I personally +1 for this
> >> change, I just wanted to give a chance to others to be prepared.
> > With rubygem-rspec1 imported, I will change all packages which currently
> > have "BR: rubygem(rspec)" to "BR: rubygem(rspec1)" and rebuild
> all those srpms.
> > If those srpm don't have FTBFS issue right now, they should also succeed on
> > building after this change (if they fail to build after this change, I guess
> > they already had FTBFS issue)
> >
> >>> I prepared rubygem-rspec-2.6.0 and rubygem-"rspec1"-1.3.2:
> >>> http://mtasaka.fedorapeople.org/Trial-rpms/rubygem-rspec-2.6.0-1.fc.src.rpm
> >>> http://mtasaka.fedorapeople.org/Trial-rpms/rubygem-rspec1-1.3.2-2.fc.src.rpm
> >>> http://mtasaka.fedorapeople.org/Trial-rpms/rubygem-rspec.spec
> >>> http://mtasaka.fedorapeople.org/Trial-rpms/rubygem-rspec1.spec
> >> Is the change in folder structure, i.e. rename from rspec to rspec1
> >> really necessary? The gems don't conflicts, so it seems to me too much
> >> effort for no benefit.
> > Well,
> > - We cannot have two "rubygem-rspec" srpm (on Fedora repository), so
> anyway
> >     one of these should be renamed on srpm name level. With srpm renamed to
> >     "rubygem-rspec1", I think reconstructuring directories and especially
> >     changing rspec-1.X.gemspec to rspec"1"-1.X.gemspec would be less
> confusing
> >     as it "matches" currently rubygem based rpms' structure
> > - Anyway I think we can agree with any of the ways.
> >
> >>> With these rpms,
> >>> - people who wants to use rspec 1 has to specify it as
> >>>       (Build)Requires: rubygem(rspec1), rubygem(rspec), and to use
> >>>       "gem 'rspec1'", not "gem 'rspec'".
> /usr/bin/spec remains as before.
> >>> - people who want to use rspec 2 will specify it as
> >>>       (Build)Requires: rubygem(rspec), and "gem 'rspec'".
> Note that
> >>>       /usr/bin/rspec is (already) in rubygem-rspec-core-2.6.4.
> >>>
> >>> If we can agree with these changes, I will submit these specs/srpms for
> >>> review requests.
> > Regards,
> > Mamoru
> >
> >
> > _______________________________________________
> > ruby-sig mailing list
> > ruby-sig(a)lists.fedoraproject.org
> > https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
>  
>  _______________________________________________
>  ruby-sig mailing list
>  ruby-sig(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/ruby-sig

[Marek Goldmann]

There is one more thing:

Now I upgraded to RSpec 2 in Fedora. I plan to submit BoxGrinder to EPEL 6, but there is
only RSpec 1.3. What would be the approach to bump RSpec there?

--Marek

On 18 lip 2011, at 18:49, Mo Morsi wrote:

>  Perhaps we can shoot for doing this w/ F17, and if we are unable to
>  migrate all the dependent packages over, then add a rspec1 compat
>  package to buy us some more time.
>  
>  In any case, would rather push this off to F17 myself as a few of us are
>  going through and updating alot of the rails related plugins to be
>  compatible w/ Rails 3 in Fedora. We're trying to get this done by the
>  F16 deadline next week. 
--Marek

[Vít Ondruch]

RSpec 2 as they are in F16 can be imported into EPEL right now. Any idea 
how many packages depends on RSpec in EPEL?


Vit



Dne 21.7.2011 20:49, Marek Goldmann napsal(a):
>  There is one more thing:
>
>  Now I upgraded to RSpec 2 in Fedora. I plan to submit BoxGrinder to EPEL 6, but there is
> only RSpec 1.3. What would be the approach to bump RSpec there?
>
>  --Marek
>
>  On 18 lip 2011, at 18:49, Mo Morsi wrote:
>
> > Perhaps we can shoot for doing this w/ F17, and if we are unable to
> > migrate all the dependent packages over, then add a rspec1 compat
> > package to buy us some more time.
> >
> > In any case, would rather push this off to F17 myself as a few of us are
> > going through and updating alot of the rails related plugins to be
> > compatible w/ Rails 3 in Fedora. We're trying to get this done by the
> > F16 deadline next week.
>  --Marek
>
>  _______________________________________________
>  ruby-sig mailing list
>  ruby-sig(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/ruby-sig

[Marek Goldmann]

For EPEL 6 - exactly 5:

$ repoquery --repoid=epel-source --arch=src --whatrequires 'rubygem(rspec)'
rubygem-extlib-0:0.9.13-5.el6.src
rubygem-facon-0:0.4.1-2.el6.src
rubygem-rack-test-0:0.5.4-1.el6.src
rubygem-thin-0:1.2.8-4.el6.src
rubygem-uuidtools-0:2.1.1-1.el6.src

For EPEL 5 - also 5:

$ repoquery --repoid=epel-source --arch=src --whatrequires 'rubygem(rspec)'
rubygem-extlib-0:0.9.13-5.el5.src
rubygem-facon-0:0.4.1-2.el5.src
rubygem-linode-0:0.6.2-1.el5.src
rubygem-thin-0:1.2.8-2.el5.src
rubygem-uuidtools-0:2.1.1-2.el5.src

--Marek

On 22 lip 2011, at 09:48, Vít Ondruch wrote:

>  RSpec 2 as they are in F16 can be imported into EPEL right now. Any
> idea 
>  how many packages depends on RSpec in EPEL?
>  
>  
>  Vit
>  
>  
>  
>  Dne 21.7.2011 20:49, Marek Goldmann napsal(a):
> > There is one more thing:
> > 
> > Now I upgraded to RSpec 2 in Fedora. I plan to submit BoxGrinder to EPEL 6, but there
> is only RSpec 1.3. What would be the approach to bump RSpec there?
> > 
> > --Marek
> > 
> > On 18 lip 2011, at 18:49, Mo Morsi wrote:
> > 
> >> Perhaps we can shoot for doing this w/ F17, and if we are unable to
> >> migrate all the dependent packages over, then add a rspec1 compat
> >> package to buy us some more time.
> >> 
> >> In any case, would rather push this off to F17 myself as a few of us are
> >> going through and updating alot of the rails related plugins to be
> >> compatible w/ Rails 3 in Fedora. We're trying to get this done by the
> >> F16 deadline next week.
> > --Marek
> > 
> > _______________________________________________
> > ruby-sig mailing list
> > ruby-sig(a)lists.fedoraproject.org
> > https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
>  
>  _______________________________________________
>  ruby-sig mailing list
>  ruby-sig(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/ruby-sig

[Mo Morsi]

Since this list is a lot shorter than the corresponding list in Fedora, 
perhaps we can get these package maintainers to update to RSpec 2.

Otherwise, perhaps we can leave it in there as there for now, push the 
rspec-core and other subcomponents to EPEL, and update the BoxGrinder 
RPM to depend on those subcomponents instead of rspec itself?

   -Mo

On 07/22/2011 09:18 AM, Marek Goldmann wrote:
>  For EPEL 6 - exactly 5:
>
>  $ repoquery --repoid=epel-source --arch=src --whatrequires 'rubygem(rspec)'
>  rubygem-extlib-0:0.9.13-5.el6.src
>  rubygem-facon-0:0.4.1-2.el6.src
>  rubygem-rack-test-0:0.5.4-1.el6.src
>  rubygem-thin-0:1.2.8-4.el6.src
>  rubygem-uuidtools-0:2.1.1-1.el6.src
>
>  For EPEL 5 - also 5:
>
>  $ repoquery --repoid=epel-source --arch=src --whatrequires 'rubygem(rspec)'
>  rubygem-extlib-0:0.9.13-5.el5.src
>  rubygem-facon-0:0.4.1-2.el5.src
>  rubygem-linode-0:0.6.2-1.el5.src
>  rubygem-thin-0:1.2.8-2.el5.src
>  rubygem-uuidtools-0:2.1.1-2.el5.src
>
>  --Marek
>
>  On 22 lip 2011, at 09:48, Vít Ondruch wrote:
>
> > RSpec 2 as they are in F16 can be imported into EPEL right now. Any idea
> > how many packages depends on RSpec in EPEL?
> >
> >
> > Vit
> >
> >
> >
> > Dne 21.7.2011 20:49, Marek Goldmann napsal(a):
> >> There is one more thing:
> >>
> >> Now I upgraded to RSpec 2 in Fedora. I plan to submit BoxGrinder to EPEL 6, but
> there is only RSpec 1.3. What would be the approach to bump RSpec there?
> >>
> >> --Marek
> >>
> >> On 18 lip 2011, at 18:49, Mo Morsi wrote:
> >>
> >>> Perhaps we can shoot for doing this w/ F17, and if we are unable to
> >>> migrate all the dependent packages over, then add a rspec1 compat
> >>> package to buy us some more time.
> >>>
> >>> In any case, would rather push this off to F17 myself as a few of us are
> >>> going through and updating alot of the rails related plugins to be
> >>> compatible w/ Rails 3 in Fedora. We're trying to get this done by the
> >>> F16 deadline next week.
> >> --Marek
> >>
> >> _______________________________________________
> >> ruby-sig mailing list
> >> ruby-sig(a)lists.fedoraproject.org
> >> https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
> >
> > _______________________________________________
> > ruby-sig mailing list
> > ruby-sig(a)lists.fedoraproject.org
> > https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
>
>  _______________________________________________
>  ruby-sig mailing list
>  ruby-sig(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/ruby-sig

[Marek Goldmann]

Hiya,

On 25 lip 2011, at 16:10, Mo Morsi wrote:

>  Since this list is a lot shorter than the corresponding list in
> Fedora, perhaps we can get these package maintainers to update to RSpec 2. 
We're talking here about:

rubygem-extlib-0:0.9.13-5.el6.src       (stahnma)
rubygem-facon-0:0.4.1-2.el6.src         (stahnma)
rubygem-rack-test-0:0.5.4-1.el6.src     (mfojtik)
rubygem-thin-0:1.2.8-4.el6.src          (mfojtik)
rubygem-uuidtools-0:2.1.1-1.el6.src     (stahnma)

>  Otherwise, perhaps we can leave it in there as there for now, push
> the rspec-core and other subcomponents to EPEL, and update the BoxGrinder RPM to depend on
> those subcomponents instead of rspec itself? 
I'm cool with this! This would be same as current Fedora rawhide state. After
upgrading above packages we could bump rubygem-rspec to 2.x.

Seems reasonable?

--Marek

>  
>   -Mo
>  
>  On 07/22/2011 09:18 AM, Marek Goldmann wrote:
> > For EPEL 6 - exactly 5:
> > 
> > $ repoquery --repoid=epel-source --arch=src --whatrequires 'rubygem(rspec)'
> > rubygem-extlib-0:0.9.13-5.el6.src
> > rubygem-facon-0:0.4.1-2.el6.src
> > rubygem-rack-test-0:0.5.4-1.el6.src
> > rubygem-thin-0:1.2.8-4.el6.src
> > rubygem-uuidtools-0:2.1.1-1.el6.src
> > 
> > For EPEL 5 - also 5:
> > 
> > $ repoquery --repoid=epel-source --arch=src --whatrequires 'rubygem(rspec)'
> > rubygem-extlib-0:0.9.13-5.el5.src
> > rubygem-facon-0:0.4.1-2.el5.src
> > rubygem-linode-0:0.6.2-1.el5.src
> > rubygem-thin-0:1.2.8-2.el5.src
> > rubygem-uuidtools-0:2.1.1-2.el5.src
> > 
> > --Marek
> > 
> > On 22 lip 2011, at 09:48, Vít Ondruch wrote:
> > 
> >> RSpec 2 as they are in F16 can be imported into EPEL right now. Any idea
> >> how many packages depends on RSpec in EPEL?
> >> 
> >> 
> >> Vit
> >> 
> >> 
> >> 
> >> Dne 21.7.2011 20:49, Marek Goldmann napsal(a):
> >>> There is one more thing:
> >>> 
> >>> Now I upgraded to RSpec 2 in Fedora. I plan to submit BoxGrinder to EPEL 6,
> but there is only RSpec 1.3. What would be the approach to bump RSpec there?
> >>> 
> >>> --Marek
> >>> 
> >>> On 18 lip 2011, at 18:49, Mo Morsi wrote:
> >>> 
> >>>> Perhaps we can shoot for doing this w/ F17, and if we are unable to
> >>>> migrate all the dependent packages over, then add a rspec1 compat
> >>>> package to buy us some more time.
> >>>> 
> >>>> In any case, would rather push this off to F17 myself as a few of us are
> >>>> going through and updating alot of the rails related plugins to be
> >>>> compatible w/ Rails 3 in Fedora. We're trying to get this done by
> the
> >>>> F16 deadline next week.
> >>> --Marek
> >>> 
> >>> _______________________________________________
> >>> ruby-sig mailing list
> >>> ruby-sig(a)lists.fedoraproject.org
> >>> https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
> >> 
> >> _______________________________________________
> >> ruby-sig mailing list
> >> ruby-sig(a)lists.fedoraproject.org
> >> https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
> > 
> > _______________________________________________
> > ruby-sig mailing list
> > ruby-sig(a)lists.fedoraproject.org
> > https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
>   
--Marek

[Mo Morsi]

>  I'm cool with this! This would be same as current Fedora rawhide
> state. After upgrading above packages we could bump rubygem-rspec to 2.x.
>
>  Seems reasonable?
>
>  --Marek
>  
Sounds good to me.

   -Mo

[Vít Ondruch]

Hello everybody,

Here is updated list of Rawhide packages which still depends on RSpec 1.3:

$ repoquery --repoid=rawhide-source --arch=src --whatrequires 
'rubygem(rspec)'
deltacloud-core-0:0.3.0-11.fc16.src (mfojtik)
jruby-0:1.6.2-2.fc16.src (mmorsi)
rubygem-bcrypt-ruby-0:2.1.2-2.fc15.src (mmorsi)
rubygem-boxgrinder-build-0:0.9.3-2.fc16.src (goldmann)
rubygem-boxgrinder-core-0:0.3.4-1.fc16.src (goldmann)
rubygem-commander-0:4.0.3-4.fc15.src (mfojtik)
rubygem-facon-0:0.4.1-2.fc15.src (stahnma)
rubygem-ffi-0:1.0.9-2.fc16.src (bkearney)
rubygem-linode-0:0.6.2-1.fc15.src (stahnma)
rubygem-multimap-0:1.1.2-3.fc15.src (mmorsi)
rubygem-rerun-0:0.5.2-4.fc15.src (mfojtik)
rubygem-scruffy-0:0.2.6-2.fc15.src (mmorsi)
rubygem-simple-navigation-0:3.0.0-3.fc15.src (mfojtik)
rubygem-thin-0:1.2.11-3.fc16.src (mfojtik, clalance)
rubygem-typhoeus-0:0.2.0-2.fc15.src (mfojtik)
rubygem-uuidtools-0:2.1.1-1.fc14.src (mmorsi)
rubygem-will_paginate-0:3.0-0.1.pre2.fc16.src (mfojtik, clalance, mmorsi)
rubygem-yard-0:0.7.2-1.fc16.src (mmorsi)

Vit

[Vít Ondruch]

Hello everybody,

Here is updated list of Rawhide packages which still depends on RSpec 1.3:

$ repoquery --repoid=rawhide-source --arch=src --whatrequires
'rubygem(rspec)'
deltacloud-core-0:0.3.0-11.fc16.src (mfojtik)
jruby-0:1.6.2-2.fc16.src (mmorsi)
rubygem-bcrypt-ruby-0:2.1.2-2.fc15.src (mmorsi)
rubygem-commander-0:4.0.3-4.fc15.src (mfojtik)
rubygem-facon-0:0.4.1-2.fc15.src (stahnma)
rubygem-ffi-0:1.0.9-2.fc16.src (bkearney)
rubygem-linode-0:0.6.2-1.fc15.src (stahnma)
rubygem-little-plugger-0:1.1.2-3.fc17.src (bkabrda)
rubygem-multimap-0:1.1.2-3.fc15.src (mmorsi)
rubygem-rerun-0:0.5.2-4.fc15.src (mfojtik)
rubygem-scruffy-0:0.2.6-2.fc15.src (mmorsi)
rubygem-simple-navigation-0:3.0.0-3.fc15.src (mfojtik)
rubygem-thin-0:1.2.11-3.fc16.src (mfojtik, clalance)
rubygem-typhoeus-0:0.2.0-2.fc15.src (mfojtik)
rubygem-uuidtools-0:2.1.1-1.fc14.src (mmorsi)
rubygem-will_paginate-0:3.0-0.1.pre2.fc16.src (mfojtik, clalance, mmorsi)
rubygem-yard-0:0.7.2-1.fc16.src (mmorsi)

$ repoquery --repoid=rawhide-source --arch=src --whatrequires 
'rubygem(rspec)' | wc -l
17

Vit

[Shawn Starr]

On Wednesday, November 16, 2011 10:48:22 AM Vít Ondruch wrote:
>  Hello everybody,
>  
>  Here is updated list of Rawhide packages which still depends on RSpec 1.3:
>   
<snip>

>  Vit 
Do we have a simple howto to convert to 2.0? Would make things easy for me to 
get my rubygems ready.

Thanks,
Shawn.

[Vít Ondruch]

Dne 17.11.2011 00:55, Shawn Starr napsal(a):
>  On Wednesday, November 16, 2011 10:48:22 AM Vít Ondruch wrote:
> > Hello everybody,
> >
> > Here is updated list of Rawhide packages which still depends on RSpec 1.3:
> >
>  <snip>
>
> > Vit
>  Do we have a simple howto to convert to 2.0? Would make things easy for me to
>  get my rubygems ready.
>
>  Thanks,
>  Shawn.
>  _______________________________________________
>  ruby-sig mailing list
>  ruby-sig(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/ruby-sig 
Hi Shawn,

No we don't, but I can throw a few points here, what I am typically doing.

1) Replace the BR: rubygem(rspec) => BR: rubygem(rspec-core). Typically 
I add above some comment like "# Use rspec-core until rspec are not 
migrated to RSpec 2.x" just to remember.
2) Use command "rspec spec/" in your check section. This typically 
replaces similar call for RSpec 1.x, which was "spec spec/"
3) Now you have to check that the test suite passes. If not, you have to 
make it compatible and submit patch upstream. Usually it is not required 
and it will just work. However sometime it needs more effort. Recent 
example might be rubygem-little-plugger [1]. You can see that the patch 
is very simple and was easily accepted by upstream.

Thats it. In the future, once all gems are RSpec 2.x ready, the 
rubygem-rspec package should be migrated from RSpec 1.x to RSpec 2.x and 
from that time, it will be possible to use again the rubygem(rspec) 
provider.


Vit


[1] https://bugzilla.redhat.com/show_bug.cgi?id=754355

[Shawn Starr]

On Friday, November 18, 2011 10:23:00 AM Vít Ondruch wrote:
>  
>  Hi Shawn,
>  
>  No we don't, but I can throw a few points here, what I am typically doing.
>  
>  1) Replace the BR: rubygem(rspec) => BR: rubygem(rspec-core). Typically
>  I add above some comment like "# Use rspec-core until rspec are not
>  migrated to RSpec 2.x" just to remember.
>  2) Use command "rspec spec/" in your check section. This typically
>  replaces similar call for RSpec 1.x, which was "spec spec/"
>  3) Now you have to check that the test suite passes. If not, you have to
>  make it compatible and submit patch upstream. Usually it is not required
>  and it will just work. However sometime it needs more effort. Recent
>  example might be rubygem-little-plugger [1]. You can see that the patch
>  is very simple and was easily accepted by upstream.
>  
>  Thats it. In the future, once all gems are RSpec 2.x ready, the
>  rubygem-rspec package should be migrated from RSpec 1.x to RSpec 2.x and
>  from that time, it will be possible to use again the rubygem(rspec)
>  provider.
>  
>  
>  Vit
>  
>  
>  [1] https://bugzilla.redhat.com/show_bug.cgi?id=754355 
Thanks Vit, 

I'll use this guide for my OpenNebula rubygem dependencies I'll be working on 
this and next month.

Shawn

[Vít Ondruch]

Hi guys,

There have been nice progress in this matter, nevertheless, there are 
still some packages which depends on RSpec 1.x:

$ repoquery --repoid=rawhide-source --arch=src --whatrequires 
'rubygem(rspec)'
deltacloud-core-0:0.4.1-6.fc17.src (mfojtik, clalance)
jruby-0:1.6.2-2.fc16.src (mmorsi, vondruch)
rubygem-ffi-0:1.0.9-2.fc16.src (bkearney)
rubygem-linode-0:0.6.2-1.fc15.src (stahnma)

$ repoquery --repoid=rawhide --whatrequires 'rubygem(rspec)'
aeolus-conductor-devel-0:0.4.0-1.fc17.noarch (mmorsi, clalance, sseago)

$ repoquery --repoid=rawhide-source --arch=src --whatrequires rubygem-rspec
rubygem-daemon_controller-0:0.2.6-1.fc16.src (pwu)




Vit

[Michael Stahnke]

Linode is in a FTBFS state anyway, due to some httparty changes.

When I am able to fix linode, it will require rspec 2.x.

On Thu, Jan 12, 2012 at 5:56 AM, Vít Ondruch <vondruch(a)redhat.com&gt; wrote:
>  Hi guys,
>
>  There have been nice progress in this matter, nevertheless, there are still
>  some packages which depends on RSpec 1.x:
>
>
>  $ repoquery --repoid=rawhide-source --arch=src --whatrequires
>  'rubygem(rspec)'
>  deltacloud-core-0:0.4.1-6.fc17.src (mfojtik, clalance)
>  jruby-0:1.6.2-2.fc16.src (mmorsi, vondruch)
>
>  rubygem-ffi-0:1.0.9-2.fc16.src (bkearney)
>  rubygem-linode-0:0.6.2-1.fc15.src (stahnma)
>
>  $ repoquery --repoid=rawhide --whatrequires 'rubygem(rspec)'
>  aeolus-conductor-devel-0:0.4.0-1.fc17.noarch (mmorsi, clalance, sseago)
>
>  $ repoquery --repoid=rawhide-source --arch=src --whatrequires rubygem-rspec
>  rubygem-daemon_controller-0:0.2.6-1.fc16.src (pwu)
>
>
>
>
>  Vit
>
>
>
>  _______________________________________________
>  ruby-sig mailing list
>  ruby-sig(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/ruby-sig

[Vít Ondruch]

Thank you. It seems that upstream version is using RSpec 2.x anyway, so 
it should be straight forward.

Vit


Dne 12.1.2012 18:53, Michael Stahnke napsal(a):
>  Linode is in a FTBFS state anyway, due to some httparty changes.
>
>  When I am able to fix linode, it will require rspec 2.x.
>
>  On Thu, Jan 12, 2012 at 5:56 AM, Vít Ondruch<vondruch(a)redhat.com>  wrote:
> > Hi guys,
> >
> > There have been nice progress in this matter, nevertheless, there are still
> > some packages which depends on RSpec 1.x:
> >
> >
> > $ repoquery --repoid=rawhide-source --arch=src --whatrequires
> > 'rubygem(rspec)'
> > deltacloud-core-0:0.4.1-6.fc17.src (mfojtik, clalance)
> > jruby-0:1.6.2-2.fc16.src (mmorsi, vondruch)
> >
> > rubygem-ffi-0:1.0.9-2.fc16.src (bkearney)
> > rubygem-linode-0:0.6.2-1.fc15.src (stahnma)
> >
> > $ repoquery --repoid=rawhide --whatrequires 'rubygem(rspec)'
> > aeolus-conductor-devel-0:0.4.0-1.fc17.noarch (mmorsi, clalance, sseago)
> >
> > $ repoquery --repoid=rawhide-source --arch=src --whatrequires rubygem-rspec
> > rubygem-daemon_controller-0:0.2.6-1.fc16.src (pwu)
> >
> >
> >
> >
> > Vit
> >
> >
> >
> > _______________________________________________
> > ruby-sig mailing list
> > ruby-sig(a)lists.fedoraproject.org
> > https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
>  _______________________________________________
>  ruby-sig mailing list
>  ruby-sig(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/ruby-sig

[Mo Morsi]

On 01/12/2012 08:56 AM, Vít Ondruch wrote:
>  Hi guys,
>
>  There have been nice progress in this matter, nevertheless, there are 
>  still some packages which depends on RSpec 1.x:
>
>  $ repoquery --repoid=rawhide-source --arch=src --whatrequires 
>  'rubygem(rspec)'
>  deltacloud-core-0:0.4.1-6.fc17.src (mfojtik, clalance)
>  jruby-0:1.6.2-2.fc16.src (mmorsi, vondruch)
>  rubygem-ffi-0:1.0.9-2.fc16.src (bkearney)
>  rubygem-linode-0:0.6.2-1.fc15.src (stahnma)
>
>  $ repoquery --repoid=rawhide --whatrequires 'rubygem(rspec)'
>  aeolus-conductor-devel-0:0.4.0-1.fc17.noarch (mmorsi, clalance, sseago)
>
>  $ repoquery --repoid=rawhide-source --arch=src --whatrequires 
>  rubygem-rspec
>  rubygem-daemon_controller-0:0.2.6-1.fc16.src (pwu)
>
>
>
>
>  Vit
>
>
>  _______________________________________________
>  ruby-sig mailing list
>  ruby-sig(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/ruby-sig 
jruby has been updated to rspec 2 as of the following commit

http://pkgs.fedoraproject.org/gitweb/?p=jruby.git;a=commitdiff;h=8d0234eb...

   -Mo

[Vít Ondruch]

Dne 20.1.2012 22:55, Mo Morsi napsal(a):
>  On 01/12/2012 08:56 AM, Vít Ondruch wrote:
> > Hi guys,
> >
> > There have been nice progress in this matter, nevertheless, there are 
> > still some packages which depends on RSpec 1.x:
> >
> > $ repoquery --repoid=rawhide-source --arch=src --whatrequires 
> > 'rubygem(rspec)'
> > deltacloud-core-0:0.4.1-6.fc17.src (mfojtik, clalance)
> > jruby-0:1.6.2-2.fc16.src (mmorsi, vondruch)
> > rubygem-ffi-0:1.0.9-2.fc16.src (bkearney)
> > rubygem-linode-0:0.6.2-1.fc15.src (stahnma)
> >
> > $ repoquery --repoid=rawhide --whatrequires 'rubygem(rspec)'
> > aeolus-conductor-devel-0:0.4.0-1.fc17.noarch (mmorsi, clalance, sseago)
> >
> > $ repoquery --repoid=rawhide-source --arch=src --whatrequires 
> > rubygem-rspec
> > rubygem-daemon_controller-0:0.2.6-1.fc16.src (pwu)
> >
> >
> >
> >
> > Vit
> >
> >
> > _______________________________________________
> > ruby-sig mailing list
> > ruby-sig(a)lists.fedoraproject.org
> > https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
>
>  jruby has been updated to rspec 2 as of the following commit
>
>
> http://pkgs.fedoraproject.org/gitweb/?p=jruby.git;a=commitdiff;h=8d0234eb...
>
>
>
>    -Mo
>  _______________________________________________
>  ruby-sig mailing list
>  ruby-sig(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/ruby-sig 
Thank you Mo!

I was afraid that JRuby might be blocker. Good to see that I was wrong.


Vit

[Vít Ondruch]

Hi guys,

It seems that we have almost eliminated usage of RSpec 1.x:

$ repoquery --repoid=rawhide-source --arch=src --whatrequires 
'rubygem(rspec)'
rubygem-ffi-0:1.0.9-2.fc16.src
rubygem-linode-0:0.6.2-1.fc15.src

$ repoquery --repoid=rawhide --whatrequires 'rubygem(rspec)'
aeolus-conductor-devel-0:0.4.0-2.fc17.noarch

$ repoquery --repoid=rawhide-source --arch=src --whatrequires rubygem-rspec
rubygem-daemon_controller-0:0.2.6-2.fc17.src

$ repoquery --repoid=rawhide --arch=src --whatrequires rubygem-rspec


The only remaining packages are:
rubygem-ffi (bkearney) - seems to be just packaging bug: 
https://bugzilla.redhat.com/show_bug.cgi?id=760009
rubygem-linode (stahnma) - upstream is already RSpec 2.x compatible, it 
is FTBFS currently and it would deserve update anyway
aeolus-conductor-devel (mmorsi, clalance, sseago) - Hm, are 
rubygem(rspec-rails) 2.6 compatible with RSpec 1.x? I doubt it ...
rubygem-daemon_controller (pwu) - It seems there should not be issue 
running with RSpec 2.x, although I did not tested it.


Could we move forward and let the rubygem-rspec to follow the upstream 
RSpec version and Require: rubygem(rspec-core)?


Vit

[Mo Morsi]

On 01/25/2012 04:46 AM, Vít Ondruch wrote:
>  Hi guys,
>
>  It seems that we have almost eliminated usage of RSpec 1.x:
>
>  $ repoquery --repoid=rawhide-source --arch=src --whatrequires 
>  'rubygem(rspec)'
>  rubygem-ffi-0:1.0.9-2.fc16.src
>  rubygem-linode-0:0.6.2-1.fc15.src
>
>  $ repoquery --repoid=rawhide --whatrequires 'rubygem(rspec)'
>  aeolus-conductor-devel-0:0.4.0-2.fc17.noarch
>
>  $ repoquery --repoid=rawhide-source --arch=src --whatrequires 
>  rubygem-rspec
>  rubygem-daemon_controller-0:0.2.6-2.fc17.src
>
>  $ repoquery --repoid=rawhide --arch=src --whatrequires rubygem-rspec
>
>
>  The only remaining packages are:
>  rubygem-ffi (bkearney) - seems to be just packaging bug: 
>  https://bugzilla.redhat.com/show_bug.cgi?id=760009
>  rubygem-linode (stahnma) - upstream is already RSpec 2.x compatible, 
>  it is FTBFS currently and it would deserve update anyway
>  aeolus-conductor-devel (mmorsi, clalance, sseago) - Hm, are 
>  rubygem(rspec-rails) 2.6 compatible with RSpec 1.x? I doubt it ...
>  rubygem-daemon_controller (pwu) - It seems there should not be issue 
>  running with RSpec 2.x, although I did not tested it.
>
>
>  Could we move forward and let the rubygem-rspec to follow the upstream 
>  RSpec version and Require: rubygem(rspec-core)?
>  

+1, lets move forward with this. I'm in the process of updating the 
aeolus-conductor codebase to work against ruby 1.9.3 and will look into 
incorporating an update to rspec 2 into this.

Since linode, ffi, and daemon_controller have been taken care of and 
we've long announced the update to rspec2 in F17, lets perform the final 
cutover. If there are issues going forward, we can easily introduce a 
rspec1 compat package.

   -Mo

[Vít Ondruch]

Dne 13.2.2012 20:40, Mo Morsi napsal(a):
>  On 01/25/2012 04:46 AM, Vít Ondruch wrote:
> > Hi guys,
> >
> > It seems that we have almost eliminated usage of RSpec 1.x:
> >
> > $ repoquery --repoid=rawhide-source --arch=src --whatrequires 
> > 'rubygem(rspec)'
> > rubygem-ffi-0:1.0.9-2.fc16.src
> > rubygem-linode-0:0.6.2-1.fc15.src
> >
> > $ repoquery --repoid=rawhide --whatrequires 'rubygem(rspec)'
> > aeolus-conductor-devel-0:0.4.0-2.fc17.noarch
> >
> > $ repoquery --repoid=rawhide-source --arch=src --whatrequires 
> > rubygem-rspec
> > rubygem-daemon_controller-0:0.2.6-2.fc17.src
> >
> > $ repoquery --repoid=rawhide --arch=src --whatrequires rubygem-rspec
> >
> >
> > The only remaining packages are:
> > rubygem-ffi (bkearney) - seems to be just packaging bug: 
> > https://bugzilla.redhat.com/show_bug.cgi?id=760009
> > rubygem-linode (stahnma) - upstream is already RSpec 2.x compatible, 
> > it is FTBFS currently and it would deserve update anyway
> > aeolus-conductor-devel (mmorsi, clalance, sseago) - Hm, are 
> > rubygem(rspec-rails) 2.6 compatible with RSpec 1.x? I doubt it ...
> > rubygem-daemon_controller (pwu) - It seems there should not be issue 
> > running with RSpec 2.x, although I did not tested it.
> >
> >
> > Could we move forward and let the rubygem-rspec to follow the 
> > upstream RSpec version and Require: rubygem(rspec-core)?
> >
>
>
>  +1, lets move forward with this. I'm in the process of updating the 
>  aeolus-conductor codebase to work against ruby 1.9.3 and will look 
>  into incorporating an update to rspec 2 into this.
>
>  Since linode, ffi, and daemon_controller have been taken care of and 
>  we've long announced the update to rspec2 in F17, lets perform the 
>  final cutover. If there are issues going forward, we can easily 
>  introduce a rspec1 compat package.
>
>    -Mo
>  
Mo,

You mentioned in the packaging discussion that you have prepared patches 
for rubygem-rspec to migrate them to RSpec 2.x, is that right? Could you 
share them with us?

Vit

[Mo Morsi]

On 02/20/2012 04:33 AM, Vít Ondruch wrote:
>  Dne 13.2.2012 20:40, Mo Morsi napsal(a):
> > On 01/25/2012 04:46 AM, Vít Ondruch wrote:
> >> Hi guys,
> >>
> >> It seems that we have almost eliminated usage of RSpec 1.x:
> >>
> >> $ repoquery --repoid=rawhide-source --arch=src --whatrequires 
> >> 'rubygem(rspec)'
> >> rubygem-ffi-0:1.0.9-2.fc16.src
> >> rubygem-linode-0:0.6.2-1.fc15.src
> >>
> >> $ repoquery --repoid=rawhide --whatrequires 'rubygem(rspec)'
> >> aeolus-conductor-devel-0:0.4.0-2.fc17.noarch
> >>
> >> $ repoquery --repoid=rawhide-source --arch=src --whatrequires 
> >> rubygem-rspec
> >> rubygem-daemon_controller-0:0.2.6-2.fc17.src
> >>
> >> $ repoquery --repoid=rawhide --arch=src --whatrequires rubygem-rspec
> >>
> >>
> >> The only remaining packages are:
> >> rubygem-ffi (bkearney) - seems to be just packaging bug: 
> >> https://bugzilla.redhat.com/show_bug.cgi?id=760009
> >> rubygem-linode (stahnma) - upstream is already RSpec 2.x compatible, 
> >> it is FTBFS currently and it would deserve update anyway
> >> aeolus-conductor-devel (mmorsi, clalance, sseago) - Hm, are 
> >> rubygem(rspec-rails) 2.6 compatible with RSpec 1.x? I doubt it ...
> >> rubygem-daemon_controller (pwu) - It seems there should not be issue 
> >> running with RSpec 2.x, although I did not tested it.
> >>
> >>
> >> Could we move forward and let the rubygem-rspec to follow the 
> >> upstream RSpec version and Require: rubygem(rspec-core)?
> >>
> >
> >
> > +1, lets move forward with this. I'm in the process of updating the 
> > aeolus-conductor codebase to work against ruby 1.9.3 and will look 
> > into incorporating an update to rspec 2 into this.
> >
> > Since linode, ffi, and daemon_controller have been taken care of and 
> > we've long announced the update to rspec2 in F17, lets perform the 
> > final cutover. If there are issues going forward, we can easily 
> > introduce a rspec1 compat package.
> >
> >   -Mo
> >
>
>  Mo,
>
>  You mentioned in the packaging discussion that you have prepared 
>  patches for rubygem-rspec to migrate them to RSpec 2.x, is that right? 
>  Could you share them with us?
>
>  Vit
>
>  _______________________________________________
>  ruby-sig mailing list
>  ruby-sig(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/ruby-sig 
Attached. All the packages which depend on rspec 1 have been taken care 
of except for rubygem-linode and aeolus-conductor (still in progress but 
should be finished soon).

Patch updates the package to ruby 1.9 and removes the majority of the 
contents, adding the dependencies on the rspec-{core|mock|expectations}, 
bringing it inline w/ the upstream gem.

   -Mo

[Vít Ondruch]

Dne 20.2.2012 12:45, Mo Morsi napsal(a):
>  On 02/20/2012 04:33 AM, Vít Ondruch wrote:
> > Dne 13.2.2012 20:40, Mo Morsi napsal(a):
> >> On 01/25/2012 04:46 AM, Vít Ondruch wrote:
> >>> Hi guys,
> >>>
> >>> It seems that we have almost eliminated usage of RSpec 1.x:
> >>>
> >>> $ repoquery --repoid=rawhide-source --arch=src --whatrequires 
> >>> 'rubygem(rspec)'
> >>> rubygem-ffi-0:1.0.9-2.fc16.src
> >>> rubygem-linode-0:0.6.2-1.fc15.src
> >>>
> >>> $ repoquery --repoid=rawhide --whatrequires 'rubygem(rspec)'
> >>> aeolus-conductor-devel-0:0.4.0-2.fc17.noarch
> >>>
> >>> $ repoquery --repoid=rawhide-source --arch=src --whatrequires 
> >>> rubygem-rspec
> >>> rubygem-daemon_controller-0:0.2.6-2.fc17.src
> >>>
> >>> $ repoquery --repoid=rawhide --arch=src --whatrequires rubygem-rspec
> >>>
> >>>
> >>> The only remaining packages are:
> >>> rubygem-ffi (bkearney) - seems to be just packaging bug: 
> >>> https://bugzilla.redhat.com/show_bug.cgi?id=760009
> >>> rubygem-linode (stahnma) - upstream is already RSpec 2.x 
> >>> compatible, it is FTBFS currently and it would deserve update anyway
> >>> aeolus-conductor-devel (mmorsi, clalance, sseago) - Hm, are 
> >>> rubygem(rspec-rails) 2.6 compatible with RSpec 1.x? I doubt it ...
> >>> rubygem-daemon_controller (pwu) - It seems there should not be 
> >>> issue running with RSpec 2.x, although I did not tested it.
> >>>
> >>>
> >>> Could we move forward and let the rubygem-rspec to follow the 
> >>> upstream RSpec version and Require: rubygem(rspec-core)?
> >>>
> >>
> >>
> >> +1, lets move forward with this. I'm in the process of updating the 
> >> aeolus-conductor codebase to work against ruby 1.9.3 and will look 
> >> into incorporating an update to rspec 2 into this.
> >>
> >> Since linode, ffi, and daemon_controller have been taken care of and 
> >> we've long announced the update to rspec2 in F17, lets perform the 
> >> final cutover. If there are issues going forward, we can easily 
> >> introduce a rspec1 compat package.
> >>
> >>   -Mo
> >>
> >
> > Mo,
> >
> > You mentioned in the packaging discussion that you have prepared 
> > patches for rubygem-rspec to migrate them to RSpec 2.x, is that 
> > right? Could you share them with us?
> >
> > Vit
> >
> > _______________________________________________
> > ruby-sig mailing list
> > ruby-sig(a)lists.fedoraproject.org
> > https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
>
>  Attached. All the packages which depend on rspec 1 have been taken 
>  care of except for rubygem-linode and aeolus-conductor (still in 
>  progress but should be finished soon).
>
>  Patch updates the package to ruby 1.9 and removes the majority of the 
>  contents, adding the dependencies on the 
>  rspec-{core|mock|expectations}, bringing it inline w/ the upstream gem.
>
>    -Mo 
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:

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.

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 :)


Vit


Vit

[Mo Morsi]

On 02/20/2012 07:20 AM, Vít Ondruch wrote:
>  Dne 20.2.2012 12:45, Mo Morsi napsal(a):
> > On 02/20/2012 04:33 AM, Vít Ondruch wrote:
> >> Dne 13.2.2012 20:40, Mo Morsi napsal(a):
> >>> On 01/25/2012 04:46 AM, Vít Ondruch wrote:
> >>>> Hi guys,
> >>>>
> >>>> It seems that we have almost eliminated usage of RSpec 1.x:
> >>>>
> >>>> $ repoquery --repoid=rawhide-source --arch=src --whatrequires 
> >>>> 'rubygem(rspec)'
> >>>> rubygem-ffi-0:1.0.9-2.fc16.src
> >>>> rubygem-linode-0:0.6.2-1.fc15.src
> >>>>
> >>>> $ repoquery --repoid=rawhide --whatrequires 'rubygem(rspec)'
> >>>> aeolus-conductor-devel-0:0.4.0-2.fc17.noarch
> >>>>
> >>>> $ repoquery --repoid=rawhide-source --arch=src --whatrequires 
> >>>> rubygem-rspec
> >>>> rubygem-daemon_controller-0:0.2.6-2.fc17.src
> >>>>
> >>>> $ repoquery --repoid=rawhide --arch=src --whatrequires rubygem-rspec
> >>>>
> >>>>
> >>>> The only remaining packages are:
> >>>> rubygem-ffi (bkearney) - seems to be just packaging bug: 
> >>>> https://bugzilla.redhat.com/show_bug.cgi?id=760009
> >>>> rubygem-linode (stahnma) - upstream is already RSpec 2.x 
> >>>> compatible, it is FTBFS currently and it would deserve update anyway
> >>>> aeolus-conductor-devel (mmorsi, clalance, sseago) - Hm, are 
> >>>> rubygem(rspec-rails) 2.6 compatible with RSpec 1.x? I doubt it ...
> >>>> rubygem-daemon_controller (pwu) - It seems there should not be 
> >>>> issue running with RSpec 2.x, although I did not tested it.
> >>>>
> >>>>
> >>>> Could we move forward and let the rubygem-rspec to follow the 
> >>>> upstream RSpec version and Require: rubygem(rspec-core)?
> >>>>
> >>>
> >>>
> >>> +1, lets move forward with this. I'm in the process of updating the 
> >>> aeolus-conductor codebase to work against ruby 1.9.3 and will look 
> >>> into incorporating an update to rspec 2 into this.
> >>>
> >>> Since linode, ffi, and daemon_controller have been taken care of 
> >>> and we've long announced the update to rspec2 in F17, lets perform 
> >>> the final cutover. If there are issues going forward, we can easily 
> >>> introduce a rspec1 compat package.
> >>>
> >>>   -Mo
> >>>
> >>
> >> Mo,
> >>
> >> You mentioned in the packaging discussion that you have prepared 
> >> patches for rubygem-rspec to migrate them to RSpec 2.x, is that 
> >> right? Could you share them with us?
> >>
> >> Vit
> >>
> >> _______________________________________________
> >> ruby-sig mailing list
> >> ruby-sig(a)lists.fedoraproject.org
> >> https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
> >
> > Attached. All the packages which depend on rspec 1 have been taken 
> > care of except for rubygem-linode and aeolus-conductor (still in 
> > progress but should be finished soon).
> >
> > Patch updates the package to ruby 1.9 and removes the majority of the 
> > contents, adding the dependencies on the 
> > rspec-{core|mock|expectations}, bringing it inline w/ the upstream gem.
> >
> >   -Mo
>
>  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?


>  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.

(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.

   -Mo

[1] http://rubygems.org/downloads/rspec-core-2.8.0.gem
[2] http://rubygems.org/downloads/rspec-2.8.0.gem
[3] http://pkgs.fedoraproject.org/gitweb/?p=rubygem-rspec-core.git

[Vít Ondruch]

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


>    -Mo
>
>  [1] http://rubygems.org/downloads/rspec-core-2.8.0.gem
>  [2] http://rubygems.org/downloads/rspec-2.8.0.gem
>  [3] http://pkgs.fedoraproject.org/gitweb/?p=rubygem-rspec-core.git
>

[Bohuslav Kabrda]

----- 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.

[Bohuslav Kabrda]

----- 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.

[Bohuslav Kabrda]

----- 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.

[Bohuslav Kabrda]

>  ----- 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.

[Vít Ondruch]

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(a)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