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

How Debian Deals with Data

Hello All, 

I currently have two packages in the archive, one small ant related
package (ant-contrib-cpptasks) and a FlightGear related package (fgrun).
But its the FlightGear packaging I want to talk about. 

For those of you that have yet to enjoy playing with FlightGear, its a
very flexible and powerful flight simulator. As a program, its not that
big, but it has lots of data. The real world scenery FlightGear uses is
massive ~10GB (I think), this can either be fetched in archives, or by
svn (using a program called terrasync). Then there is also the aircraft,
numbering in there hundreds (~3GB). Now as far as I know, this amount of
data cannot be included in the Debian archives? While there may be
perfectly reasonable practical reasons why this cant happen, it is
probably inconvenient for those that can install a tiny portion of the
scenery and a few of the aircraft through the package system, but then
have to struggle fetching the rest by some other less convenient

Now I was thinking about this, and came up with a few ideas, I will
explain probably the best one. If any of you use flash, you might use
the flashplugin-nonfree package, now because cant be included in the
Debian archives, this package actually downloads the adobe installer and
then runs it. Now while this is of cause not a perfect situation. It did
get me thinking, what about doing this for the FlightGear data? 

So, imagine. The user wants to install a portion of the scenery, so they
use whatever package manager and install the relevant package. Now
behind the scenes, the package has picked out a default fetch method
(probably terrasync), and then fetched the data to the correct directory
(could ever find the best mirror). Now what about a different user that
wants the data in archive form, they could use a debconf interface to
select the correct fetch method. Now imagine that a user has the scenery
on dvd (as the project sells to raise funds for charity), the package
could check for this, and if possible install from there.

The actual package would just contain the rules and checksums for the
files it tries to fetch, but not the data itself, I think of this as a
symbolic package. This approach in my opinion, would make packaging
applications like FlightGear much easier, and improve the user

Any thoughts, or have I found a non-existent problem?



Attachment: signature.asc
Description: This is a digitally signed message part

Reply to: