Re: Bug#694418: ITP: fits -- Java library for the I/O handling of FITS files
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 <email@example.com> 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: This package has a name suggesting that it belongs to a section other
>> N: than the one it is currently categorized in.
>> N: Severity: normal, Certainty: possible
>> N: Check: fields, Type: binary, udeb, source
>> 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
> ant jar
> 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:
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
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
> * You should provide a repackaging script that creates the original
> .tar.gz from the upstream .jar file
That's another good idea, thanks!