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

[Thorsten Alteholz]

Hi Ole,

On 04.11.23 11:05, Ole Streicher wrote:
> 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.

do you mean the leap-second-patch?

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

I am afraid we are talking past each other. Am I right that you mean the 
current version of astropy in Debian? As you mentioned that 
astropy-iers-data is an upcoming  dependency of python3-astropy, I had a 
look at that new version. In this version astropy/utils/iers/iers.py 
contains a config option "auto_download" and a function "download_file()".
So while the current version of astropy in main is fine, the upcoming 
version might have a problem ...

>
> The data *are* useful, at least if you don't need the maximum accuracy 
> wrt. IERS data.

Ok, that is your call as a maintainer, so please reupload the package.

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

But keep in mind that there is more than backports, which for example is 
closed for the LTS versions.

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

*blush* you are right.

>
> 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),

The GR 2004-3 amended the DFSG to be not only valid for software but 
also for other content. So I think this part of the policy needs an update.

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

I don't use this package, but according to the description the main 
purpose of it is to display maps. So if you create your own maps, you 
can use the software without downloading external data. This sounds 
different to a script whose sole purpose is to download external data.

    Thorsten
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/debian-astro-maintainers/attachments/20231104/70b86c8d/attachment.htm>