> I suppose I could complain that maybe the reliance on an environment > variable to point to the scenery may be great for scenery developers, > but isn't so great for package maintainers who might like to try and > make (say) FlightGear-LakeConstance-Scenery-0.9.9-0.rpm > > Rather difficult for the post-install script in a package to make sure > that the users' environment gets updated to know about the new scenery. > Even more difficult to remove it cleanly and correctly afterwards when > they uninstall the package.
There is an XML property for the scenery path. A packager can create a preferences.xml with an included subfile which would be maintained automatically by such packages, adding/removing lines for things like LkConstance scenery and such. Actually, there's no harm in having non-existing paths listed on the scenery path IIRC. One could even create a package for each tile, and have virtual packages depending on such packages, for either 10x10 tiles, or countries, or states, or whatever else. (But nothing will beat a GUI-map-based interface, which is a bit difficult to implement within your typical minimalist curses-based package manager like aptitude). Vassilii _______________________________________________ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
