Hi Ole (cc: hi Steffen), thank you very much for your very useful comments!
Am 03.12.2012 17:02, schrieb Olе Streicher: > Hi Florian, > > Florian Rothmaier <froth...@ari.uni-heidelberg.de> writes: >> Section: science > [...] >> >> So far, my binary package is called "libfits-java". In that case, >> lintian complains about the section chosen for the package: >> >> W: libfits-java: wrong-section-according-to-package-name libfits-java => java >> N: >> N: This package has a name suggesting that it belongs to a section other >> N: than the one it is currently categorized in. >> N: >> N: Severity: normal, Certainty: possible >> N: >> N: Check: fields, Type: binary, udeb, source >> N: >> >> Apart from the too generic name of my package (see Ole's remark >> below), what is considered good practice for naming a scientific >> java package? > > I would put it into the "java" section since it is a java library. That > it may be used by other science packages does not matter here, IMO. > > This is basically the same as for shared libraries which go into the > "libs" section regardless whether they are specific for a scientific > purpose only. Or all documentation going into the "doc" section. > > The section does not matter much here since the package would be mostly > as a dependency, and not as an individual package. The lattes is useful > only for development, and in this case the "debtags" > <http://wiki.debian.org/Debtags> system should help to provide the > needed information. I put it (back) to the "java" section. That had been my original plan before I read the debian-science policy. > >> @Ole: Following the recommendation of the debian-legal guys, I put >> the Debian package under the CC0. > > Fine, thanks. > > Some more comments on the build: > > * Your "rules" file contains the rules > > override_dh_auto_build: > ant jar > > override_dh_auto_install: > ant javadoc > > Why do you create the javadoc not in the build, but in the install step? Thanks for that remark, Ole! The frank answer to your question is 'I don't know' ;-) So now I create the javadoc in the build step. > > * You should try to provide a "watch" file, although this may be a bit > complicated in your case: > > > http://heasarc.gsfc.nasa.gov/docs/heasarc/fits/java/v1.0/v1.10.0/fits_src.jar As you've written: it's complicated in this case. But is it feasible? The "uscan" manpage gives an example on how to scan directories recursively which is what I need # This one shows that recursive directory scanning works, in either of # two forms, as long as the website can handle requests of the form # http://site/inter/mediate/dir/ http://tmrc.mit.edu/mirror/twisted/Twisted/(\d\.\d)/ \ Twisted-([\d\.]*)\.tar\.bz2 http://tmrc.mit.edu/mirror/twisted/Twisted/(\d\.\d)/Twisted-([\d\.]*)\.tar\.bz2 but then the matching files would all have the name "fits_src.jar" and "uscan" would not see if one of them is newer than the local version. Or am I wrong? I could also ask the upstream contact to provide versioned source archives in the future. > > * You should provide a repackaging script that creates the original > .tar.gz from the upstream .jar file That's another good idea, thanks! > > Cheers > > Ole > > Cheers, Florian -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50cf4790.7020...@ari.uni-heidelberg.de
