[Debian-astro-maintainers] astropy-iers-data_0.2023.10.23.00.29.54-1_amd64.changes REJECTED

[Ole Streicher]

Hi Thorsten,

On 04.11.23 10:17, Thorsten Alteholz wrote:
> are you aware of "astropy.utils.iers.conf.auto_max_age" which
> defaults to 30 days?  After this period, there will be a warning that
> the IERS data are to old and need to be updated. I didn't check
> everything but this warning might raise an exception later on.

I am aware of this. It is just a warning, nothing more. The Debian
package adds a specific "ignore" to pytest, so that the warning does not
let the tests fail. This was discussed with upstream to avoid the need
of updating the package.

> Actually to avoid this warning, there is some auto update mechanism
> that downloads new data periodically. So in order to work, parts of
> astropy depend on external data, which is the definition of
> "contrib".

The package works well without this update, so there is no "need" to do 
this. And there is no "auto-update" mechanism in the binary package. 
There is a mechanism to automatically create a new upstream package with 
updated data every week. But this is how upstream organizes their work, 
not what happens in the Debian package.

>> Why would you consider the package as "contrib"?
> 
> Given that the data inside astropy-iers-data are not really useful,
> the only remaining part of this package is update_data.sh. But the
> only purpose of this script is to download external data, which makes
> the package belonging to contrib.

The data *are* useful, at least if you don't need the maximum accuracy 
wrt. IERS data. This is not a yes/no question: Most of the use cases 
don't need the updates at all, but ofcourse there are some which need 
it. Other use cases don't even *want* to have updates, for reproducibility.

If the updates are considered relevant for many use cases, the way to 
update would be either backports, or (if the data in stable are 
considered worthless now) with an "important" bug and a subsequent 
upload to stable-updates; there is no need to deviate from this standard 
Debian workflow.

The update_data.sh script is not even part of the binary package, and it 
is also not called during build. So it cannot be used as an argument.

And, BTW, from the Debian policy 4.6.2, I don't see why dependency on 
external data would make the package not suitable for main:

* it does not require software outside of main to function (this 
requirement is restricted to software, and data is not software),
* it is DFSG compliant
* it does not declare a relationship (in d/control, as stated in the 
policy) to a package outside of main
* it is not buggy
* it is policy compliant

A similar case is the "Gnome Maps" application, which is useless without 
external map data, and which is in Debian main.

Best

Ole