Re: Bug#694418: ITP: fits -- Java library for the I/O handling of FITS files

[Florian Rothmaier <frothmai@ari.uni-heidelberg.de>]

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 <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.

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