Bug 726690

Ill start helping as my time allows me ;)

First i noticed the naming of the rpms, please refer to http://fedoraproject.org/wiki/Packaging:NamingGuidelines#Multiple_packages_with_the_same_base_name

so i to change them to:

* rubygem-rails2.3.12
* rubygem-actionmailer2.3.12
* rubygem-actionpack2.3.12
* rubygem-activerecord2.3.12
* rubygem-activeresource2.3.12
* rubygem-activesupport2.3.12

Thanks Guillermo Gómez!

Updated packages at http://xls01.freecult.org/pkg/

Now in a git repository, so I can keep track of what I am doing.

If you are unfamiliar with the gitweb interface: Click rails23, then click snapshot next to the most recent version to download the specs/srpms.

Two issues:

_I prefer the use of the dot_

rubygem-actionmailer2.3-2.3.12-1.fc15.src.rpm instead of
rubygem-actionmailer23-2.3.12-1.fc15.src.rpm

The second issue and more important issue is about splitting this BZ in singles. Each package in the future will need to be tracked here so having multiples specs/srpms refered will make it messy. So i suggest to close and open single bz per pkg.

Parallel benefit, u just need to get sponsor for ONE pkg to get into packagers group, and others packagers could help you with the rest (im interested in rails 2.3.x for redmine)

Im interested in getting redmine as fast as possible into Fedora, but im also interested u get promoted.

rgds
Guillermo

Hi guys, why don't you spend time bringing Redmine to Rails 3.x instead of archaeology? If Redmine don't get updated to Rails 3.x it will become soon abandoned as well as Rails 2x.x and there are other competitors [1]

One of commitments of Fedora is "First", i.e. to bring the newest, bleeding edge technologies, but that are not Rails 2.x. There is no new development, no new features, anything. It just brings in potential problems with version conflicts, e.g. some package will be updated for newer Rails but will be incompatible with Rails 2.x, security, etc.

[1] https://github.com/teambox/teambox

(In reply to comment #4)
> Hi guys, why don't you spend time bringing Redmine to Rails 3.x instead of
> archaeology? If Redmine don't get updated to Rails 3.x it will become soon
> abandoned as well as Rails 2x.x and there are other competitors [1]

So on the same reasoning, why dont you go first and invest your time and package teambox instead on questioning others people interest on archaelogy? (i guess u have your reasons, so do we to be interested in redmine as it is right now and to make it available to our users)

I dont think redmine will be abandoned and yes they are working on rails 3 support [2] (u can work on that too)

Also it will be so much quicker to have rails2.3 stack available for a year or so and that would eventually empower other webapss without tweaking rubygems stack in Fedora, not only Redmine (there are many webapps that probably will not migrate to rails3 on the mid term) What about epel scenario?

> One of commitments of Fedora is "First", i.e. to bring the newest, bleeding
> edge technologies, but that are not Rails 2.x. There is no new development, no
> new features, anything. It just brings in potential problems with version
> conflicts, e.g. some package will be updated for newer Rails but will be
> incompatible with Rails 2.x, security, etc.

This is not about Rails 2.x vs Rails 3.x this is about webapps that are usefull to our users that do not work now in Fedora as it is. Redmine even running under Rails 2.x, does not mean they can not get new features and from my standing point of view, Redmine is probably the best project management web application available today, and used by many (but of course im biased).

Im a regular redmine user and i really dont care about what's behind it (talking as a user) and i keep seeing new features and developing in it. [3]

Actually we, as Fedora, are indebted with our community because the lack of redmine availability ! I just feel we should not wait, and also, yes, bring teambox to the game ! :)

> [1] https://github.com/teambox/teambox

[2] http://www.redmine.org/issues/4796
[3] http://www.redmine.org/projects/redmine/activity

Just to remind you, Redmine was already submitted for a review a long time ago [1] and the review was never finished in times when Rails 2.3 was standard. Apparently there was not high enough demand, otherwise somebody would finish that.

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

(In reply to comment #6)
> Just to remind you, Redmine was already submitted for a review a long time ago
> [1] and the review was never finished in times when Rails 2.3 was standard.
> Apparently there was not high enough demand, otherwise somebody would finish
> that.

Perhaps, maybe the demand was just solved using others method (that's what i did). Or maybe was not just me ... (just speculations).

Appearances can be deceiving and that's not a reason to say there was not a high demand or use (maybe not in Fedora, but again we are just speculating here).

Ruby/Rails community gets along with or without rpms from Fedora...

If this gets too complicated, i will abandon it too and keep using pure gems approach.

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

Thanks again Guillermo Gómez

I have renamed the packages and split out the dependencies into new review requests.

actionmailer: https://bugzilla.redhat.com/show_bug.cgi?id=728242
actionpack: https://bugzilla.redhat.com/show_bug.cgi?id=728248
activerecord: https://bugzilla.redhat.com/show_bug.cgi?id=728249
activeresource: https://bugzilla.redhat.com/show_bug.cgi?id=728255
activesupport: https://bugzilla.redhat.com/show_bug.cgi?id=728256

I think it is not necessary to close this ticket. This ticket can be the review request for the rubygem-rails2.3 package.

Direct link to SPEC: http://xls01.freecult.org/pkg/?p=pkg.git;a=blob_plain;f=SPECS/rubygem-rails2.3.spec;hb=refs/heads/rails23
Direct link to SRPM: http://xls01.freecult.org/pkg/?p=pkg.git;a=blob_plain;f=SRPMS/rubygem-rails2.3-2.3.12-1.fc15.src.rpm;hb=refs/heads/rails23

(In reply to comment #0)
> Since rails 2 and rails 3 are perfectly parallel installable, I would like to
> maintain rails 2.3 series in Fedora until it really becomes obsolete.

Btw Rails 2 and Rails 3 will conflict at least by its binary, i.e. /usr/bin/rails

(In reply to comment #8)
> Thanks again Guillermo Gómez
> 
> I have renamed the packages and split out the dependencies into new review
> requests.
> 
> actionmailer: https://bugzilla.redhat.com/show_bug.cgi?id=728242
> actionpack: https://bugzilla.redhat.com/show_bug.cgi?id=728248
> activerecord: https://bugzilla.redhat.com/show_bug.cgi?id=728249
> activeresource: https://bugzilla.redhat.com/show_bug.cgi?id=728255
> activesupport: https://bugzilla.redhat.com/show_bug.cgi?id=728256
> 
> I think it is not necessary to close this ticket. This ticket can be the review
> request for the rubygem-rails2.3 package.
> 
> Direct link to SPEC:
> http://xls01.freecult.org/pkg/?p=pkg.git;a=blob_plain;f=SPECS/rubygem-rails2.3.spec;hb=refs/heads/rails23
> Direct link to SRPM:
> http://xls01.freecult.org/pkg/?p=pkg.git;a=blob_plain;f=SRPMS/rubygem-rails2.3-2.3.12-1.fc15.src.rpm;hb=refs/heads/rails23

What about the others? Are u going to open them or not? You can keep this one for the rubygem-rails2.3 package.

(In reply to comment #10)
> (In reply to comment #8)
> > Thanks again Guillermo Gómez
> > 
> > I have renamed the packages and split out the dependencies into new review
> > requests.
> > 
> > actionmailer: https://bugzilla.redhat.com/show_bug.cgi?id=728242
> > actionpack: https://bugzilla.redhat.com/show_bug.cgi?id=728248
> > activerecord: https://bugzilla.redhat.com/show_bug.cgi?id=728249
> > activeresource: https://bugzilla.redhat.com/show_bug.cgi?id=728255
> > activesupport: https://bugzilla.redhat.com/show_bug.cgi?id=728256
> > 
> > I think it is not necessary to close this ticket. This ticket can be the review
> > request for the rubygem-rails2.3 package.
> > 
> > Direct link to SPEC:
> > http://xls01.freecult.org/pkg/?p=pkg.git;a=blob_plain;f=SPECS/rubygem-rails2.3.spec;hb=refs/heads/rails23
> > Direct link to SRPM:
> > http://xls01.freecult.org/pkg/?p=pkg.git;a=blob_plain;f=SRPMS/rubygem-rails2.3-2.3.12-1.fc15.src.rpm;hb=refs/heads/rails23
> 
> What about the others? Are u going to open them or not? You can keep this one
> for the rubygem-rails2.3 package.

Ooops i missed the others open bz already.. forget my previous comment

(In reply to comment #9)
> Btw Rails 2 and Rails 3 will conflict at least by its binary, i.e.
> /usr/bin/rails

Thank you Vít Ondruch

I have thought about this and believe this not to be the case. The content of the /usr/bin/rails script in the rails2.3 package and the rails 3 package is exactly the same. Here is it in full: 

> #!/usr/bin/ruby
> #
> # This file was generated by RubyGems.
> #
> # The application 'rails' is installed as part of a gem, and
> # this file is here to facilitate running it.
> #
> 
> require 'rubygems'
> 
> version = ">= 0"
> 
> if ARGV.first =~ /^_(.*)_$/ and Gem::Version.correct? $1 then
>   version = $1
>   ARGV.shift
> end
> 
> gem 'rails', version
> load Gem.bin_path('rails', 'rails', version)

If you have both rails 2 and rails 3 installed, it defaults to using rails 3: 

$ rails --version
Rails 3.0.5

But you can call it asking for a specific version:

$ rails _2.3.12_ --version
Rails 2.3.12

$ rails _3.0.5_ --version
Rails 3.0.5

Of course I am open to a difference of opinion. Do you have any suggestions? Perhaps I could leave /usr/bin/rails out of the rails-2.3 package. It is also possible to make a /usr/bin/rails2 script that defaults to using rails2. We only need to change one line. 

- version = ">= 0"
+ version = "< 3"

(In reply to comment #12)
> (In reply to comment #9)
> > Btw Rails 2 and Rails 3 will conflict at least by its binary, i.e.
> > /usr/bin/rails
> 
> Thank you Vít Ondruch
> 
> I have thought about this and believe this not to be the case. The content of
> the /usr/bin/rails script in the rails2.3 package and the rails 3 package is
> exactly the same. Here is it in full: 
> 
> > #!/usr/bin/ruby
> > #
> > # This file was generated by RubyGems.
> > #
> > # The application 'rails' is installed as part of a gem, and
> > # this file is here to facilitate running it.
> > #
> > 
> > require 'rubygems'
> > 
> > version = ">= 0"
> > 
> > if ARGV.first =~ /^_(.*)_$/ and Gem::Version.correct? $1 then
> >   version = $1
> >   ARGV.shift
> > end
> > 
> > gem 'rails', version
> > load Gem.bin_path('rails', 'rails', version)
> 
> If you have both rails 2 and rails 3 installed, it defaults to using rails 3: 
> 
> $ rails --version
> Rails 3.0.5
> 
> But you can call it asking for a specific version:
> 
> $ rails _2.3.12_ --version
> Rails 2.3.12
> 
> $ rails _3.0.5_ --version
> Rails 3.0.5
> 
> Of course I am open to a difference of opinion. Do you have any suggestions?
> Perhaps I could leave /usr/bin/rails out of the rails-2.3 package. It is also
> possible to make a /usr/bin/rails2 script that defaults to using rails2. We
> only need to change one line. 
> 
> - version = ">= 0"
> + version = "< 3"

Hmm traditionally renaming old binary is the way to go, i asked, but ill do it again.

$ mv /usr/bin/rails /usr/bin/rails2.3 (in pkg building)

Thank you, Guillermo Gómez,

New rails package with /usr/bin/rails moved to /usr/bin/rails2.3

Patched the file to make it default to rails 2, even if rails 3 is installed.

(In reply to comment #12)
You are right, they are the same ... but they are the same just as long as the package is prepared using the same version of RubyGems. In that case it seems that RPM can handle it correctly.

Thank you, Vít Ondruch.

There is probably no harm in moving the script to /usr/bin/rails2.3 and making it default to rails 2 even when rails 3 is installed.

Or would you suggest to revert that change?

Updated package to fix rpmlint error

SPEC:
http://xls01.freecult.org/pkg/?p=pkg.git;a=blob_plain;f=SPECS/rubygem-rails2.3.spec;hb=refs/heads/rails23
SRPM:
http://xls01.freecult.org/pkg/?p=pkg.git;a=blob_plain;f=SRPMS/rubygem-rails2.3-2.3.12-1.fc15.src.rpm;hb=refs/heads/rails23
ChangeLog:
http://xls01.freecult.org/pkg/?p=pkg.git;a=log;h=refs/heads/rails23

I was using %{_sourcedir}, changed it to %{SOURCE1}. This is now the rpmlint output:

$ rpmlint /var/lib/mock/fedora-15-i386/result/*.rpm

rubygem-rails2.3.noarch: W: spelling-error %description -l en_US eRuby -> e Ruby, Ruby, ruby
rubygem-rails2.3.noarch: E: zero-length /usr/lib/ruby/gems/1.8/gems/rails-2.3.12/lib/rails_generator/generators/components/mailer/templates/fixture.rhtml
rubygem-rails2.3.noarch: E: zero-length /usr/lib/ruby/gems/1.8/gems/rails-2.3.12/configs/empty.log
rubygem-rails2.3.noarch: E: zero-length /usr/lib/ruby/gems/1.8/gems/rails-2.3.12/lib/rails_generator/generators/components/mailer/templates/view.rhtml
rubygem-rails2.3.noarch: E: zero-length /usr/lib/ruby/gems/1.8/gems/rails-2.3.12/html/favicon.ico
rubygem-rails2.3.noarch: W: no-manual-page-for-binary rails2.3
rubygem-rails2.3.src: W: spelling-error %description -l en_US eRuby -> e Ruby, Ruby, ruby
rubygem-rails2.3.src:58: W: macro-in-comment %patch
rubygem-rails2.3.src:77: W: macro-in-comment %{buildroot}
rubygem-rails2.3.src:77: W: macro-in-comment %{geminstdir}
2 packages and 0 specfiles checked; 4 errors, 6 warnings.

I hope the zero-length files are acceptable. Rails requires them, see: https://bugzilla.redhat.com/show_bug.cgi?id=496480

They are because the requirement : http://fedoraproject.org/wiki/Common_Rpmlint_issues#zero-length

The other W are tipical from ruby source files vs rpmlint in, ignore them.

With the move to ruby 1.9, making rails 2.3 compatible has become much more difficult in recent Fedora releases. Additionally, several projects requiring rails 2.3 previously now support rails 3, including redmine. I am abandoning this effort.