Hi Peter, On Sat, Jul 23, 2011 at 12:22:25PM -0400, Peter Bennett wrote: > Many thanks for doing this. > > I used rsync since cp -a was trying to copy the svn directories. For > some reason I am not sure of, it was failing with an error that it was > unable to create the svn directories in the destination directory. I did > not look further into why that was, but just changed to rsync. If you > think that is abuse I can investigate the svn issue again. Well, as I've said it's not wrong to use rsync here but it feels a bit weird when reading the packaging the first time as using rsync somewhat suggests that there may be stuff pulled from the net which of course would be a no-go. After reading more into the matter it's perfectly clear that you use it only to shuffle around files locally but that was where my comment came from. I'll leave it up to you to decide what's the best version for your package. I could also think of using two tar processes with pipe in between to achieve the same result. That's the great benefit of having so many different (and valid) solution in the open source world! > I put leading zeroes in my version number thinking that in future if I > went from 2.9 to 2.10 it would be considered as a lower version > somewhere. Perhaps my 3 part version number is a bit excessive. I'm quite sure that you may be interested in this: $ dpkg --compare-versions 2.9.1-1 lt 2.10.1-1&&echo ok ok $ and luckily also: $ dpkg --compare-versions 02.09.1-1 lt 2.10.1-1&&echo ok ok $ So sorry but I can't buy that excuse. ;-) > I am not sure what is so bad about a relative classpath in a jar file. I > can get rid of the duplicate icon file. Feeding the warning into lintian-info I read: N: N: The classpath listed in the jar file refers to a potential missing jar N: file. This could be the remnants of a build-time classpath that are N: not relevant for a JAR bundled in a Debian package. N: N: Alternatively, the classpath may be correct, but the package is N: lacking a jar file or a symlink to it. N: N: Note, Lintian assumes that all (relative) classpaths pointing to N: /usr/share/java/ (but not subdirs thereof) are satisfied by N: dependencies as long as there is at least one strong libX-java N: dependency. N: N: Severity: normal, Certainty: possible N: N: Check: java, Type: binary N: So if you can confirm this is not a problem as explained by lintian you may want to put an override and have this ignored from now on. -- Best regards, Kilian
Attachment:
signature.asc
Description: Digital signature