Hi,
> Influenced by the discussion on debian-devel list[1] I have the
following suggestion for the main purpose to provide test data
for Debian Med packages:
> 1. create a package debian-med-testdata
> 2. this package should ship those larger data sets that would
occupy "to much" space in binary packages
> 3. Install those data to
> /usr/share/debian-med/data/PKGNAME
I'm personally not very convinced to create a central data repository for the following reasons:
1. I suppose, our original goal for providing autopkgtest data in a separate binary was mainly because we wanted users to be able to get there binaries as test data and run our shipped tests on them.
Creating a central repository with huge chunks of data will not only be an inconvenience for us, but also for the end users - our users might not have the motivation to download several gigabytes of unrelated data just to test one package.
Even if we create a symlink, we will still need the central repository anyway.
2. If we do new changelog revisions (for example, assigning version numbers according to current date)
while inserting a new data and doing an upload, then for each of the uploads, we'd everytime end up with a huge "orig.tar.gz" file which is a waste of space, for each of its snapshots.
3. A few(many?) Of our packages already have a "-data" binaries already. So creating a centralised package would cause problem in both the two cases:
a) If we scrape the "-data" binary (for all the packages which have a binary just for the testing data), and move all of the data/examples to the centralised repository, I suppose we have to upload this to NEW?
b) if we choose to not scrape the "-data" binary and create a centralised repository for data, then this would lead to an inconsistency across packages. Some of which have a "-data" and the others fetching it from the centralised repository.
To me, creating a separate source package in this way[1] sounds like a more promising solution.
Let me know what you'd think, and apologies if I said something wrong.
Kind Regards,
Nilesh