[pkg-fgfs-crew] flightgear 3.2 packaging

[Rebecca Palmer]

I have fixed a bug in the script, and added the option to downsample 
-base-textures.

> Do you envision us bundling our own data tarballs?
If you just want to use this script, I'd just add it somewhere in 
debian/ (it's all mine so no copyright issue).

> AFAIUI the script has been committed upstream. Does that mean they are
> anywhere close to split flightgear-data into multiple separate tarballs?
> (Maybe optionally available alongside the full thing?)
Committed by me, with a proposal to do that 
(http://sourceforge.net/p/flightgear/mailman/message/32473710/), which 
nobody replied to.

> why treat the 777 special?
Just its 220MB size (against 75MB total for the others); if you still 
want to include it, that's fine with me.  A third option would be to 
include it but as its own package.

> One point that I'm worried about is that I see no reason for a split as
> long as you need both parts, anyways.
I'd agree if they are always going to both be required, but if we think 
something could be optional but want to do more testing/add better error 
reporting first, making it a separate package with a hard Depends for 
now avoids a second NEW-queue trip later.

With that in mind:

>   * flightgear-data-models: currently split, but I see no good reason
>     for that split. Merge back into base?
Agreed.  (I suspect ~half of this is unused or redundant with the copy 
Terrasync downloads, but the way to deal with that (once I can reliably 
identify the parts in question, so probably not until 3.4) would be to 
remove or move to -scenery, not a separate package.)

>   * flightgear-data-base-textures: mandatory, not currently
>     split. Should go into base, IMO.
>
>   * flightgear-data-extra-textures: optional - either split by
>     region specific vs global or downsampled vs full resolution. Is
>     there any overlap with base-textures? Or can we provide extra
>     textures as their own files, which flightgear uses when available
>     and gracefully handles when absent? I'm unclear on how 'optional'
>     these are.
>
>     Can we combine the two split points, i.e. provide just the
>     downsampled version of the global textures in -base? And put all of
>     the other 3 combinations into -extra?
You can now:
python3 -c "import fgdata_checkers; 
fgdata_checkers.create_reduced_fgdata(input_path='/home/palmer/fs_dev/git/fgdata',output_path='/home/palmer/fs_dev/flightgear/data_split/debian/flightgear-data-{0}/usr/share/games/flightgear',dirs_to_downsample=('Textures.high/Terrain','Textures.high/Trees','Textures.high/Terrain.winter'))"

With a global/regional split there's no overlap, i.e. flightgear 
Depends: flightgear-data-base-textures, Recommends: 
flightgear-data-extra-textures, but with a downsampled/full split there 
is (downsampled textures are placed instead of the full one in the same 
location, not using the Textures/Textures.high split, because the latter 
doesn't work for textures used in effects), i.e. Depends: 
flightgear-data-extra-textures | flightgear-data-base-textures, and the 
two would Conflict, requiring -base-textures to be separate from -base.

For future flexibility, I'd make -base-textures separate (and call the 
other one -extra-textures rather than -regional-textures) even if 
they're global/regional in 3.2.

The size of -base-textures is approximately 175MB global-fullres, 87MB 
global-downsampled, or 152MB all-downsampled.

>   * flightgear-data-scenery:[...]Would or should flightgear
>     running w/o this installed automatically enable Terrasync?
No, both because users trying to save limited/expensive bandwidth might 
not realise omitting this package then makes things worse, and because 
it's generally considered a privacy breach for packages to contact an 
online service without the user asking for it (see the privacy-breach-* 
Lintian tags; Terrasync is hosted on Google).  As Terrasync on/off is a 
saved user setting, we'd also only be allowed to do this for new 
installs, not upgrades.

Displaying a 'scenery not installed, to install it go to File > Scenery 
Download' message (instead of just water) on attempting to go to a 
non-installed airport would be a good idea (with or without making this 
package optional, since it also happens on selecting an out-of-area 
location), but possibly should be done upstream.

>   * flightgear-data-ai: currently split, hopefully really optional.
>     Again, ideally flightgear should emit a warning if --enable-ai is
>     given, but this package isn't installed. And the corresponding
>     option in fgrun & fgo should be disabled.
Currently, enabling AI traffic just silently does nothing if this isn't 
installed; I agree this isn't ideal.

(Unlike the old -ai package, removing mine only disables background 
traffic, not tankers/carriers/...; as some (small) files were moved from 
-ai to -base to do this, Breaks+Replaces are required.)

>   * flightgear-data-aircraft: currently split, seems really optional,
>     but with some overlap with the upcoming Aircraft Center.
It's my opinion that when Aircraft Center ceases to be experimental (so 
probably 3.4) the aircraft should be removed from flightgear-data (so 
this package would then cease to exist), but nobody commented (either 
way) when I proposed this upstream.