[DRE-maint] Some comments on the redmine package

[Jean-Philippe Garcia Ballester]

	Hi,
	Here are some comments and thoughts about the Richard Hurt's 
redmine package Richard Hurt. My mail server is broken and I am unable 
to answer to one of his mail, please excuse me for the disturbance.

	First, I have to say that I'm very glad and grateful to see that rails 
apps are being packaged in Debian. It seems Passenger will also be 
packaged in Debian soon, and it will make deployments and 
maintenance of rails app really easy.

	However, since this is the first rails app that will be package in 
Debian, I think that others will take it as an example, and I fear that if 
the package has a few things to fix, these few things will have to be 
fixed in more that one package. AFAIK redmine won't be in lenny, so I'd 
rather see the first rails package to be as good as possible.

	Anyway, here is what I've seen so far:
	* Use debconf in your postinst, to ask the user if
		* he wants to configure the database.yml file
		* he wants to create the db
		* he wants to load default data
		* he wants to configure a webserver (apache2 fcgid / apache2 
mod_rails / …)
	* The sample apache configuration you provide has AFAIK the 
following problems:
		* It will not work out of the box. If you do not wish to use 
debconf to ask the user which way he wants, you should add in the 
apache2.conf a working configuration (e.g. with mod_fcgid), and in 
comments other working configurations (e.g. with mod_rails).
		* Why put a VirtualHost with a DocumentRoot? This is 
confusing, the Alias alone would work better IHMO.
		* The commented VirtualHost DocumentRoot lacks “/public” at 
the end.
	* The README.Debian files contains requirements for running 
redmine. They are IMHO useless, because it is the job of the package to 
ensure the requirements are fullfilled (except for optionnal stuff like db 
and webserver configuration). Thus, I think removing the first two lines 
and modifying debian/control to add dependency on ruby1.8 and rails 
(>= 2.1), rails (<= 2.2) is better.
	* The debian/redmine.lintian-overrides overrides things that should 
not be overriden, and hides bugs.
		* The “script-not-executable” warnings: having a shebang and 
not being executable is contradictory. Either the script can be used as a 
binary, and should be executable, or it is not and then the shebang 
useless.
		* The ”package-contains-empty-directory”: your comment 
says “These directories hold temporary data”. However, /usr/share is 
meant to be read-only, and shipping empty directories there is a bug. 
Either the program write something in the directory, and this is a bug, 
or the program doesn't write anything and the directory is useless.
	* I think the “public” directory should go in /usr/share, because 
AFAIK it is not meant to be changed, neither at runtime nor by the user.
	* Plugins should go in separate Debian packages. I am against a 
package in Debian which ships totally different and independant 
software.
	* In the “debian/redmine.logrotate” file, you create the log files in 
mode 0666. I think it should be 0644, or maybe 0640. Also, according 
to man page, the create option has no effect when copytruncate is used, 
so maybe you should just remove the create option.
	* You are using the svn version of redmine to build the package. I 
am not sure, but I think the 0.7.4 release will not be a snapshot of the 
svn, but rather backporting bugfixes without introducing new features. 
Thus, if you ship the svn now, and then the 0.7.4 when it is released, 
there might be regression features. It might be better to use 0.7.3 and 
backport patches for rails 2.1.
	* In the “debian/copyright” file, remove references to 
“vendor/rails”, since they are not shipped in the Debian package.
	* You mix in the debian/patches/dispatch.patch two different 
things: using /usr/bin/env instead of calling ruby directly, and fixing the 
path to RAILS_ROOT. I think it should be splitted in two, with a short 
comment of what the patch does and why.
	* The patch also contains whitespace changes (adding a newline at 
the end of files).
	* I think symlinking directories in /usr/share is not, as a user's point 
of view, the best thing to do. I prefer to have on my system a clean 
directory structure, rather that symlinks everywhere to fix software not 
respecting the FHS. This seems to me more like a workaround instead of 
a real fix, and I think we should try to see how much work it is to patch 
things to allow configurating the different paths. Some work would need 
to be done directly in Rails, but if a clean patch is made and applied 
upstream, this would fix it for other packages and distributions.

	I'm willing to help fixing these issues, however, I'm in the middle of 
fixing my computer for the moment and I do not have as much time on 
this as I would.

	Regards,

-- 
Jean-Philippe Garcia Ballester