FlightGear package manager
| This article is a stub. You can help the wiki by expanding it. |
| Started in | ... |
|---|---|
| Description | Provides an integrated package manager for installing/managing and uninstalling aircraft and other fgdata resources |
| Maintainer(s) | Zakalawe |
| Contributor(s) | Zakalawe (since) |
| Status | Under active development as of 03/2015. |
| Package management |
|---|
|
Background |
|
Implementation |
|
Front Ends
|
|
Related efforts |
| Note In its current form, this section/article is largely based on quotes collected from various related discussions/channels (devel list, forum etc) using the Instant-Cquotes script. Wiki users and other contributors are encouraged to help rewrite/edit contents accordingly to help get rid of unnecessary quoting (i.e. while the wiki is not intended to be a collection of quotes, quotes are sometimes the best/easiest way to bootstrap new articles, while also providing a good way to link back to related discussions in the archives).
While rewriting usually only entails changing first person speech to 3rd person. However, please try to retain references/links to the original discussion whenever possible. |
| Note The Integrated Qt5 launcher has a hangar download feature and is included in FlightGear 3.6+. |
Background
TheTom and Zakalawe have begun working on an aircraft package manager, the backend pieces are mostly there but will need some intensive testing. The UI is implemented via Canvas and Nasal in the form of the Aircraft Center. There is a #define flag you can toggle (in HTTPClient.cxx) to enable the code including the Nasal API; it will download / refresh a catalog, which is generated by the scripts committed to fgmeta. Then you can access the package system from pkg.root in the Nasal Console, using the API defined at the bottom of HTTPClient.cxx[1] [1].
The idea to encourage hangar authors to ideally use some standard tooling to create their XML, or alternatively we need to provide some XML verification tools around it. Given that property-list XML is not easy to check with an XML schema, any suggestions on a ‘catalog compliance check’ are welcome; we could write one in Python using the same scripts used to generate the official catalog.[2]
Issues
|
I’ve been working on the package code so it’s ready for 3.6, must admit I’ve not been paying attention to 3.4.1
— James Turner (2015-04-24). Re: [Flightgear-devel] When is 3.4.1 planned?.
(powered by Instant-Cquotes) |
|
|
|
The default aircraft catalog download path is http://fgfs.goneabitbursar.com/pkg/<version>/default-catalog.xml, which — Rebecca N. Palmer (2015-03-31). [Flightgear-devel] Non-existent default catalog.
(powered by Instant-Cquotes) |
|
Objective
Tthe goal here is to almost get rid of a centralised aircraft repo anyway, and have a decentralised development system with the only central point being the aircraft package manager for end users. Then 99% of people never care where the aircraft is stored while it’s developed[3].
The goal is that no one except people working on an individual aircraft should care where it’s developed at all (on GitHub, in a private SVN repo, stored as sheets of paper in a filing cabinet). SCM systems are not distribution/release systems, we’ve simply been using them in that fashion by accident[4]
The intention is that adding additional ‘hangars’ (aka ‘catalogs’) will be trivial. And anyone can host a hangar, it’s deliberately de-centralised. There is also the expectation that some hangars might have different license terms, e.g. some Creative Commons license which is incompatible with the GPL. (Then we need to decide, how we explain this to users, but right now they download a .zip from a website and don’t care about the license at all).[5]
Then the role of the development team is simply to select which aircraft appear (in each release) in the official catalog (hangar). Obviously we would only select from GPLd aircraft, but beyond that the aircraft could be developed anywhere at all.
And I would expect/hope other people to curate hangars based on their choices - e.g. based on time period (WW2), type of aircraft (gliders) or whatever. Often these people might be the aircraft developers themselves (e.g. FGUK team or Lake Of Constance) but again the code doesn’t care. Of course once the technical system is in place there are some social discussions around this to figure out :) [6]
Security
Please be aware that the code downloads zips, unpacks them, makes calls to unlink files, renames directories, and so on. So, some caution is recommended, and especially, don’t run it as root (while developing it, Zakalawe had it extract a few zips to ‘/‘ or worse due to screwed up path logic).
A code review of the code in simgear/package/Install.cxx to check any security issues or dangerous behaviour would be appreciate. The code /tries/ to be ‘safe’ - extract zip to a temporary folder, and uses rename/unlink to atomically update if the zip extraction succeeds. But it’s only had one pair of eyes on it so far[7].
|
|
Well, if we make a manual catalog.xml from the current fgdata/Aircraft (which I have parts of a script to do), and we treat the current aircraft zip URLs as canonical, that is possible with current code right now - since it can do the zip download + extraction to a directory of our choice. We could throw an (ugly) PUI UI around that, and then if someone with more talent than me wants to Canvas-GUI-ify it, that will be great. I will attempt to get a prototype version of this working tonight / tomorrow. I don’t promise to produce anything usable but as you say, anything would be an improvement. — James Turner (2014-05-30). Re: [Flightgear-devel] select/download aircraft.
|
|
Development
If you wish to dig into the package system, and create some tooling so it’s easy to publish releases from a Git repo to a web-host, please do. The current script is in fgmeta; see ‘create_catalog.py’ which runs over FGData of course, but you can imagine something similar for any SCM store containing several aircraft. There’s additional features that can be added of course, such as support for ‘beta’ or ‘testing’ versions of aircraft, being able to exist alongside stable versions. That would require some C++ hacking on the client side but pretty straightforward stuff I think. [8]
|
|
My long term goal here would be that fg-aircraft goes away, and we actually specify aircraft via their package ID only, with no aircraft-dir set either. But that’s a much bigger step.
(Of course only in a world where all aircraft are run from a package, we still need these options for ad-hoc aircraft and development) — James Turner (2015-04-03). Re: [Flightgear-devel] Launcher issues on Linux.
(powered by Instant-Cquotes) |
|
|
|
The dependencies system has never been tried, but the intent is to allow non-aircraft packages of shared resources to be used (i.e common files for all aircraft in a hangar), the question is what option(s) are used to add those packages to the aircraft search list at runtime. Probably the fg-aircraft mechanism is exactly what is needed here.
— James Turner (2015-04-03). Re: [Flightgear-devel] Launcher issues on Linux.
(powered by Instant-Cquotes) |
|
|
|
Historically, FlightGear tends to re-invent the wheel more often than not unfortunately - but adopting a package/plugin framework would definitely make sense. While we can certainly proceed without one, the outcome is likely to be hugely incompatible and cause a ton of chaos - once you think about just how many features were/are developed as "addons", some more attention should be given to such considerations and requirements (bombable, advanced weather, fgcamera, tutorials etc)
|
|
|
|
The question is how far we'd want to go with something like this - because at some point, it would make more sense to adopt an existing package management system that is multi-platform and open source (e.g. pacm or miniconda). Otherwise, most of the building blocks for a simple package manager are already available to Nasal, i.e. http bindings and SGPath wrappers to download stuff into $FG_HOME and install stuff there. Even though it would probably make sense to also expose zlib (i.e. for extracting compressed archives). Metadata for package names, dependencies, URLs and version/description info could be provided via existing PropertyList XML files. So there's very little missing to pull this off, and a simple prototype for an existing addon, like FGCamera, should be fairly straightforward to build - it's mainly a matter of integrating existing technologies properly, and exposing them first to scripting space. But most of the infrastructure is already available, i.e. was implemented for installing aircraft and managing scenery via TerraSync. |
|
- ↑ http://sourceforge.net/p/flightgear/mailman/message/32440549/http://sourceforge.net/p/flightgear/mailman/message/32440549/
- ↑ James Turner (Apr 12th, 2016). Re: [Flightgear-devel] Built-in launcher: reproducible segfault when downloading an aircraft.
- ↑ http://sourceforge.net/p/flightgear/mailman/message/33413096/
- ↑ http://sourceforge.net/p/flightgear/mailman/message/33550567/
- ↑ http://sourceforge.net/p/flightgear/mailman/message/33594007/
- ↑ http://sourceforge.net/p/flightgear/mailman/message/33594007/
- ↑ http://sourceforge.net/p/flightgear/mailman/message/32440549/http://sourceforge.net/p/flightgear/mailman/message/32440549/
- ↑ http://sourceforge.net/p/flightgear/mailman/message/33550567/