Redmine

Richard Hurt wrote:

• There are two versions of prototype.js installed in 3 different locations (listed below). Would it be possible to standardize on one version (1.6.x)? What would be involved in getting this fixed?
  • public/javascripts/prototype.js

This is Redmine's JavaScript.

• vendor/rails/actionpack/lib/action_view/helpers/javascripts/prototype.js
• vendor/rails/railties/html/javascripts/prototype.js

These come bundled with Rails and are not used except when Rails generates an application. You can ignore vendor/rails if you install the correct Rails gem in your package. vendor/rails is just a local copy of the Rails gem.

• There are several scripts (i.e. script/about, vendor/plugins/rfpdf/lib/rfpdf/makefont.rb, /vendor/rails/railties/bin/runner) that are not executable. Are these files not used anywhere or are they imported somehow and then executed? If they are imported can we remove the #! from the top of the file?

script/* are used a lot from the shell and should be executable. See above for the vendor/rails scripts. I'm not sure about rfpdf.

• These files have the wrong #! path. It should be #!/usr/bin/env ruby. Where do I submit a patch for these files?

The path used is based on the Ruby environment for whoever generated the first copy of Redmine. You can submit a patch here to use /usr/bin/env.

Actually, tearing out the vendor/rails stuff removed quite a bit of cruft from my build. I didn't know that when Rails generates an application it includes stuff in the vendors directory. Thats good to know. The only glaring errors I have left are some scripts that should be executable but aren't.

These scripts are executables but they don't have the execute bit set. Should I open a Redmine ticket to get this changed?

• extra/svn/reposman.rb
• extra/svn/svnserve.wrapper

These scripts are also missing the execute bit, but since they are a vendor I don't quite know what to do with them. Any suggestions?

• vendor/plugins/coderay-0.7.6.227/bin/coderay
• vendor/plugins/coderay-0.7.6.227/bin/coderay_stylesheet
• vendor/plugins/rfpdf/lib/rfpdf/makefont.rb
• vendor/plugins/rfpdf/test/test_helper.rb

I just double checked the permissions and it looks like the ones in SVN are correct but somehow when it moves to the .tar.gz they get hosed up. I also checked the .zip but it looks like it doesn't correctly store the permissions either. Checking back through a number of old builds it looks like these scripts have never had the execute bit set properly on them.

This looks like a bug in the generation of the .tar.gz file. Should I open a separate ticket for it or just tag it onto this one?

Richard Hurt wrote:

Actually, tearing out the vendor/rails stuff removed quite a bit of cruft from my build. I didn't know that when Rails generates an application it includes stuff in the vendors directory. Thats good to know.

Partily correct. A Rails application requires the Rails gems (think library) installed somewhere. This can be in a system directory ( /var/lib/gems/1.8/gems in Debian), a user directory (like HOME/.gems), or in vendor/rails. Since system gems might be upgraded at any time, most Rails applications bundle Rails and other third party libraries with their code.

These scripts are executables but they don't have the execute bit set. Should I open a Redmine ticket to get this changed?

• extra/svn/reposman.rb
• extra/svn/svnserve.wrapper

I would say no. Those are optional scripts that are copied to other locations when setting up Apache controlled subversion access. They shouldn't be executable in the main install.

These scripts are also missing the execute bit, but since they are a vendor I don't quite know what to do with them. Any suggestions?

• vendor/plugins/coderay-0.7.6.227/bin/coderay
• vendor/plugins/coderay-0.7.6.227/bin/coderay_stylesheet
• vendor/plugins/rfpdf/lib/rfpdf/makefont.rb
• vendor/plugins/rfpdf/test/test_helper.rb

I would leave them as is. Some plugins have scripts that can be run on the command line but are not used in Redmine.

Richard Hurt wrote:

I just double checked the permissions and it looks like the ones in SVN are correct but somehow when it moves to the .tar.gz they get hosed up.

A tar file should store permissions. Maybe it's getting packaged incorrectly, go ahead and open a ticket for it.

I also checked the .zip but it looks like it doesn't correctly store the permissions either.

I don't think the zip file format store permissions at all.

Created ticket #1753 to address the .tar.gz permissions problems.

BTW: Is it possible to make issues dependent upon one another in Redmine? I would like to make this issue depend on 1753 but I didn't see any way to do that from the Issue Update screen.

I have a few points to say on this:

• Each plugin (in vendor/plugins) should be AFAIK provided in a separate Debian package built from upstream source, since there shouldn't be code duplication between different apps.
• I think vendor/rails should be a symlink to /usr/share/rails, or config/boot.rb should be patched to load the Debian provided one. Not sure which is best, but under no circumstances should the Debian package include rails nor depend on a gem.
• It should be made FHS compliant (e.g. logs in /var/logs, doc in /usr/share/doc/redmine, etc).
• Since you don't seem to have great knowledge of either Debian packaging and Rails development, I suggest you ask for help/reviewal on the Debian/Ruby Extras team mailing list (http://lists.alioth.debian.org/mailman/listinfo/pkg-ruby-extras-maintainers/). If you do so, could you please send me a private message as I don't actually read the list?
• I'm willing to help if you need/wish. Though not an expert, I have a little knowledge of Debian policy and Rails, and maybe I could help you to achieve better quality.

Jean-Philippe Garcia Ballester wrote:

I have a few points to say on this:

• Each plugin (in vendor/plugins) should be AFAIK provided in a separate Debian package built from upstream source, since there shouldn't be code duplication between different apps.

Agreed.

• I think vendor/rails should be a symlink to /usr/share/rails, or config/boot.rb should be patched to load the Debian provided one. Not sure which is best, but under no circumstances should the Debian package include rails nor depend on a gem.

vendor/rails is currently symlinked to /usr/share/rails and it seems to be working just fine. Are there any good/bad reasons to symlink vs. patching config/boot.rb? Which one is easier to maintain or more "proper"?

• It should be made FHS compliant (e.g. logs in /var/logs, doc in /usr/share/doc/redmine, etc).

Agreed (and done).

• Since you don't seem to have great knowledge of either Debian packaging and Rails development, I suggest you ask for help/reviewal on the Debian/Ruby Extras team mailing list (http://lists.alioth.debian.org/mailman/listinfo/pkg-ruby-extras-maintainers/). If you do so, could you please send me a private message as I don't actually read the list?

I am in contact with the Ruby guys and Debian Mentors list and they have been a wonderful resource. I will add you to my status updates so that you can more easily voice your opinion.

• I'm willing to help if you need/wish. Though not an expert, I have a little knowledge of Debian policy and Rails, and maybe I could help you to achieve better quality.

Thank you!
Richard

Jean-Philippe Garcia Ballester wrote:

• I'm willing to help if you need/wish. Though not an expert, I have a little knowledge of Debian policy and Rails, and maybe I could help you to achieve better quality.

Ummm... I need your email address. :) Please drop me a note at rnhurt(at)kangarooboxD0Tcom.

Thanx!
Richard