Re: Bug#694418: ITP: fits -- Java library for the I/O handling of FITS files
Hi Florian,
Florian Rothmaier <frothmai@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.
> @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?
* 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
* You should provide a repackaging script that creates the original
.tar.gz from the upstream .jar file
Cheers
Ole
Reply to: