Lee Elliott wrote:

The downside would be that an installer/un-installer would become a necessity.

I think that issue was discussed some time ago on the user list ?

Probably, it would already be sufficient to simply package aircraft
folders as tar archives in order to simplify installation ?

If I am not wrong, FlightGear is already linked to libz.a - so
basically it supports already dealing with compressed files,
at least that's exactly what FlightGear is doing with the navaids
database under $FG_ROOT/Navaids.

So, it would be pretty straight forward to simply open an archive,
look for a specific XML file that describes the aircraft/contents
or rather look for the corresponding tags within an XML file such
as *-set.xml and display the encountered information, so that the
user can choose whether to install (=extract all its contents to a
specific location) the (aircraft) archive or not.

Actually keeping track of aircraft that are installed in non-standard
locations (!=$FG_ROOT/Aircraft) would indeed require some kind of
list with those locations that are already in use, so that
FlightGear can also check for available aircraft there.

Uninstalling is of course a whole different matter, at least taking
into account that Aircrafts can theoretically have cross-references
to other Aircraft's components - so one would want to preserve such

That's where RPM comes in ;-)

At a minimum, only the paths need be stored, together with the classification tags, but who could resist the temptation of storing absolute a/c components...

Well, using a clever loop, one COULD (optionally) make FlightGear validate its aircraft files automatically and make it check for aircraft definition files that are using relative paths instead of available variables for FlightGear's subfolders, so that these could be 'fixed'.

Basically, FlightGear would recursively read in all files and check
the resulting absolute path for all relative paths - IF a resulting
path is equal to a supported "short cut" variable, it could replace
the corresponding relative path. If a relative path doesn't match any
pre-defined variables, one could at least change them in a way, so that
they refer to $FG_ROOT - which would also result in maintaining
dependencies regardless of the actual file's location.

Something like that might in come handy anyway, when it comes to
'fixing' the current files ...

-------- Boris

_______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d

Reply via email to