[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: