[DRE-maint] Redmine package uploaded

[Richard Hurt]

On Aug 12, 2008, at 6:37 PM| Aug 12, 2008, Gunnar Wolf wrote:

> Richard Hurt dijo [Mon, Aug 11, 2008 at 04:48:03PM -0400]:
>>
>> - Soft linking things that don't belong in /usr/share.  I have
>>  moved the files/ and log/ directories, but config/ and public/
>>  probably need to go to /var/lib as well.
>
> Yes, I think symbolic links are the sanest way to go. The RAILSROOT
> would be at /usr/share/redmine - Of course, there are other potential
> things to consider... Maybe in the first place we can pretend to
> ignore this, but it would be much better to provide a way to install
> multiple instances of the system... I am working out some ideas ;-)

Yes, I'm giving myself a break on the first pass.  Lets get it working  
reasonably well and then nail it down.

>> - The rules file is still pretty ugly, but it works.
>
> There is a very simple pattern in there - you can substitute many of
> the lines by "rm -f debian/redmine/usr/share/redmine/vendor/plugins/ 
> */*LICENSE*"
>
> ...Although it would be MUCH better not to ship all that as plugins,
> but as separate packages. Shipping a package as this one, with all of
> the plugins just in there, goes against overall quality assurance :-(

Again, a first pass thing.  As plugins get packaged we can migrate to  
them.

>> - I need a clean process for:
>>    - downloading the latest SVN from upstream
>
> That's handled via debian/watch - But we don't like following SVN - it
> is better to track released versions. Any package uploaded to Debian
> must be worth including in a stable release :-)

I had my watch file working when I was tracking their stable release,  
but when I moved to the SVN feed I had to ditch it.  When they release  
0.7.4 with Rails 2.1 support I'm going back to the tar ball.

>
>>    - diff'ing between the versions
>
> Well, it is handled in SVN, so "svn diff" will help. And between two
> .deb packages, you can use debdiff.

I was trying to find a way to show what changed between upstream  
versions so that I could modify my package accordingly.  Does debdiff  
tell you if they added a new LICENSE file or changed the tmp/  
structure of the upstream package?

>>    - building the package
>
> svn-buildpackage is your friend

I'm looking for a single command build that will pull down the  
upstream tar ball, patch everything, and build a .deb out of it.  Is  
that possible?  I'm looking to satisfy the 2nd rule of the Joel test (http://www.joelonsoftware.com/articles/fog0000000043.html 
).

>
>>    - updating pkg-ruby-extras
>
> Updating what?

I have no idea.  :)

>
>> Building this package has forced me to think about RoR apps in
>> general and where the fit into Debian.  According to the rules
>> /usr/share is for things that don't change between installs and /var
>> is for things that do.  With most of the app being outside resources
>> (Rails, Vendor, etc.) and very little actually living in /usr/share,
>> does it make sense to have anything in /usr/share?  I tried to move
>> config/ to a soft-link but it didn't like it very well.  I'm just
>> wondering what else will go wrong when/if I soft-link more things
>> out to /var.  Or is soft-linking the wrong way to go?  Hmm...
>
> The right place for most of the project's files is /usr/share. I would
> think on something +- like this, at least for the first incarnation:
>
> /usr/share/redmine
>    base Rails application install. Everything in your application
>    directory (i.e. your RAILS_ROOT) should be here, unless noted as
>    something else
> vendor/rails
>    Symlink to /usr/share/rails
> vendor/plugins/*
>    Symlinks to individual plugin packages
>    (i.e. /usr/lib/ruby/1.8/acts_as_tree and so)
> log
>    Symlink to /var/log/redmine
> tmp
>    Symlink to /tmp (or /var/tmp? Or maybe even /tmp/redmine or
>    /var/tmp/redmine ...)
> config
>    Symlink to /etc/redmine

Looks good to me.  I have already configured some of those links  
(rails, log, tmp) but had some trouble with config/.  I also tried to  
move public/ but I'm not sure thats necessary or wise.  Would public/  
be a good candidate to move to /var or are its files static?

> Now, it would be good to add on the future the ability to host
> multi-site installations. I don't have a ready example right now, but
> it could be with a host-named directory structure
> (i.e. /etc/redmine/www.example.com/ )

Redmine itself can host multiple projects with role based permissions  
so I'm not sure that you would need it.  I guess this kinda goes along  
with my public/ question above.

> Now, several bits regarding your packaging:
>
> - Your debian/watch file does not work - It gets confused with the
>  redmine-livedemo links. This fixes it:
>
> --- debian/watch   (revision 2941)
> +++ debian/watch   (working copy)
> @@ -1,2 +1,2 @@
> version=3
> -http://rubyforge.org/frs/?group_id=1850 .*/redmine-(.*)\.tar\.gz
> +http://rubyforge.org/frs/?group_id=1850 .*/redmine-(\d.*)\.tar\.gz

Thanx!

> - Do not blindly "fix" lintian messages by adding overrides. Lintian
>  is a great tool and does its job quite well. Remove empty
>  directories if they are not needed instead of hiding them. Check if
>  the mentioned scripts are meant to be executed, and mark them as
>  executable if needed - or patch them (i.e. removing the
>  #!/usr/bin/ruby line) if not.

I didn't want to use *any* lintian overrides, but for my first pass I  
just wanted it to be a clean build.  The copyright override will be  
removed in the next version and the empty directories need to be there  
for Redmine expansion modules and such so I'm not sure if they belong  
or not.  The script-not-executable was discussed on mentors a bit and  
my thinking was that these are scripts called by other things and are  
not really meant to be executable by the user.

> - Wow, your usage of redmine.install and redmine.link files is very
>  nice :-D Clear and to the point... I wonder why that's not more
>  often used!

I was just doing what I thought looked correct.

> - What's the deal with control vs. control.good and copyright
>  vs. copyright.full? I see that in control you have two different
>  sets of dependencies...

Oops, my bad.  Those were my primitive source control before I moved  
it into SVN.  I'll get rid of them.

>
> - Anyway, WOW++ on your copyright files ;-) I guess (I hope!) they  
> were
>  automatically generated. How did you do them? And, for extra points,
>  why listing exhaustively every file, instead of grouping them
>  (i.e. with wildcards, by project, or whatever). The copyright files
>  must make it obvious why it is preferrable to split this package on
>  the different plugins/libraries it provides

I blogged a bit about the copyright files (http://kangaroobox.blogspot.com/2008/07/debian-packaging-ii-simplified.html 
) and I don't think I'm finished yet.  Like you point out there are a  
lot of individual files.  I couldn't find a clean way to group them so  
I just listed them all for completeness.  :)

>
> - You are depending on Debhelper 7, but your debian/rules file is with
>  the general format of previous versions. That's not bad per se, but
>  for a fresh package, it could make sense to keep it smaller and
>  cleaner :)

I don't understand Debhelper at all or why I would depend on v7.  It  
probably generated like that or I read about it on a web page  
somewhere.  Please guide me.

> Anyway, I've been looking on-and-off at your packaging for a couple of
> hours, but attention keeps being robbed away to other tasks. Before
> anything else, GOOD JOB, and thanks a lot for coming up with this!

Thank you for taking the time to look at it.  I'm going to tweak it a  
bit over the next few days and probably "release" another Alpha  
version for people to look at.  One question I have is where to put my  
other files (.deb, .orig.tar.gz, .dsc, .diff. etc.)?  Is there  
someplace on Alioth or should I use mentors.debian.net or something  
else?  How do I go about getting some space to upload these files for  
other people to look at?  I don't want to keep filling up your email  
box.   :)

Later...
   Richard