Re: casacore-data
Thibaut Paumard <thibaut@debian.org> writes:
> Le 02/10/2014 14:29, heroxbd@gmail.com a écrit :
>> The casa table format is open, so the binary generated data can be
>> converted back to ascii if desired. Therefore the transparency issue is
>> not that severe.
> If you can't do that, casacore-data will go non-free. If casacore-data
> goes to non-free and casacore depends or recommends casacore-data, then
> casacore goes to contrib instead of main.
Formally this may be true; however I would not support (and not sponsor)
casacore going to contrib and casacore-data to non-free. Non-free and
contrib are not a real part of Debian, they are just there for a
pragmatic reason that some software just cannot released as free.
But casacore *is* free (as in DFSG), it just has some questionable test
data. So, disable the tests that rely on non-free data and we are
there. As a first step, just disable any test that needs the data
package -- they can be re-enabled once a (free) casacore-data is in
Debian.
>> The difficulty does not lie only in circular dependency. The unit tests
>> of casacore use ephemerides/VGEO and geodetic/{TAI_UTC,IGRF}. The
>> script of measuresdata.csh from casacore-data only generates
>> geodetic/{IERSeop{2000,97},IERSpredict{,2000},TAI_UTC}. I am wondering
>> if Gijs knows how to generate ephemerides/VGEO and geodetic/IGRF.
Gijs wrote that there are actually several institutes that generate
their local casacore-data tar file. So it just cannot be so difficult to
do so.
>> That's why I would go for uploading casacore tables (open-binary data)
>> first
>
> You can do that, sure. To non-free.
>
>> and then figure out how to build them from ascii sources. The
>> latter is complex enough, and it is not necessary to block the former.
As Thibaut wrote, then casacore is in contrib (and -data in
non-free). Bringing them back to main is an additional step of
complication, which needs a re-approval by the (already overloaded)
Debian ftp-master team. So, the simpler way is to
1. first disable *any* test that depend on casacore-data
2. build casacore (I will sponsor and upload it)
3. create a casacore-data package as far as you know how to build it
from ASCII source. Again, I will sponsor and upload it to main
4. enable all tests of casacore that work with this -data package; I
will sponsor this new release as well
5. on a medium term, find out how to build the missing parts of
casacore-data and re-create new releases as you feel a need for it
6. re-enable the according tests
Advantages:
* everything is in main from the beginning
* no need to go through NEW a second time (may take ages, especially for
contrib or non-free: my wcslib-contrib package took more than four
months to be accepted in contrib). Avoids additional work for the
ftp-masters.
* We ensure that we always have a high-quality, source-maintainable
casacore-data package.
* We establish a way to add/converge the local casacore-data tar files.
* We make sure that we know the origin and the structure of our data
* "main" is much better supported than contrib or non-free: the packages
are auto-build on all platforms and inofficial ports (which already is
a great quality check!), they are regularly checked by several QA
teams and are subject of several test builds (like with clang).
The people doing ports/checks/tests are really very helpful and often
find out where the (potential) problem is, sometimes you already get a
patch that fixes it. This is not to underestimate.
Disadvantages:
* additional work:
- finding and disabling all tests in step 1 and step 3
- re-enabling of tests when the data are there (step 4)
* Because of disabled tests, a buggy casacore package may slip into
Debian (at least for some architectures). This will however be worked
out when the tests come back, so it is only temporarily
* upstream somehow needs to share his magic to generate the tables
(I would however even think this is an advantage on the long run!)
* When upstream introduces new data, or changes their interface, we
would probably need to follow up
In my opinion, the advantages clearly win over the disadvantages.
Best regards
Ole
Reply to: