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

[Ole Streicher]

Hi Torsten,

On 04.11.23 19:38, Thorsten Alteholz wrote:
> 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?

Yes.

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

Keeping this as true as default would be a privacy violation of astropy 
(and needs to be patched out - thanks for the discovery), but not of the 
new package. Keeping this active is not a requirement.

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

Will do.

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

As I said: if the data render unusable for the major use case, it would 
be done via an "important" bug and an subsequent upload to stable-updates.

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

Do you mean this?

https://www.debian.org/vote/2004/vote_003

This is about the Social Contract, which is about freedom and not about 
requiring the download of (public domain) data in the installed package.

Packages requiring a data download do not violate the Social Contract 
(otherwise, they couldn't even be in contrib), and the opinion whether 
the Debian Policy needs an update cannot be an argument; valid is the 
current one and not a possible future one.

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

At least the default is to use OpenStreetMap, and there are no settings 
visible to the user to change this.

Cheers

Ole