[Debian-med-packaging] Question about proper archive area for packages that require big data for operation

[Laszlo Kajan]

Hello Andreas!

On 23/04/13 12:23, Andreas Tille wrote:
> On Tue, Apr 23, 2013 at 11:48:05AM +0200, Laszlo Kajan wrote:
>>
>> This email is to continue the discussion about free packages that depend on big (e.g. >400MB) free data outside 'main'.
> 
> In your practical case is this data say <500MB?  Are we talking about
> compressed or uncompressed data (= >400MB on users harddisk or on all
> Debian mirrors world-wide)?

It is around 404MB, gzip compressed [1]. I think it is not arch independent. I think BLAST databases (the main bulk in the tar.gz) are sensitive
to the size of int, and endian-ness.

[1] ftp://rostlab.org/metastudent/metastudent-data_1.0.0.tar.gz

> We do actually have examples of >500MB binary packages:
> 
> udd at ullmann:/srv/mirrors/debian$ find . -type f -size +500M -name "*.deb"
> ./pool/main/f/freefoam/freefoam-dev-doc_0.1.0+dfsg-1_all.deb
> ./pool/main/libr/libreoffice/libreoffice-dbg_4.0.3~rc1-3_amd64.deb
> ./pool/main/libr/libreoffice/libreoffice-dbg_4.0.3~rc1-3_kfreebsd-amd64.deb
> ./pool/main/libr/libreoffice/libreoffice-dbg_4.0.3~rc1-2_amd64.deb
> ./pool/main/libr/libreoffice/libreoffice-dbg_4.0.3~rc1-2_kfreebsd-amd64.deb
> ./pool/main/n/ns3/ns3-doc_3.16+dfsg1-1_all.deb
> ./pool/main/n/ns3/ns3-doc_3.15+dfsg-1_all.deb
> ./pool/main/w/webkitgtk/libwebkit2gtk-3.0-0-dbg_1.11.91-1_amd64.deb
> ./pool/non-free/r/redeclipse-data/redeclipse-data_1.4-1_all.deb
> 
> Even if the topic should be clarified in general because we will
> certainly have larger data sets than this in the future I could imagine
> that packaging this very data in your case should not be the main
> problem under the current circumstances as long there is no better
> solution found.
> 
> I would even go that far that it might make sense to package these data
> and upload it to demonstrate that we should *really* create a solution
> for such cases if they will increase in the number and size of data
> packages.

All right, we will package and upload the big data in case no one thinks of a better solution and discussion dies in, say, a week.

Laszlo