FlightGear package manager: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
(layout; cat) |
||
Line 1: | Line 1: | ||
{{Stub}} | {{Stub}} | ||
{{Package Management}} | {{Package Management}} | ||
{{WIP}} | {{WIP}} | ||
{{cquote | {{cquote | ||
Line 81: | Line 82: | ||
}} | }} | ||
}} | }} | ||
[[Category:Core development projects]] |
Revision as of 01:58, 7 March 2015
This article is a stub. You can help the wiki by expanding it. |
Package management |
---|
Background |
Implementation |
Front Ends
|
Related efforts |
Work in progress This article or section will be worked on in the upcoming hours or days. See history for the latest developments. |
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.
|
Thomas Geymayer and I are working on it, I am not sure where’s he go to with the UI, the backend pieces are mostly there but will need some intensive testing. 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 I committed to fgmeta a week ago. Then you can access the package system from pkg.root in the Nasal console, using the API defined at the bottom of HTTPClient.cxx. If you are crazy enough to enable this code, and run it, be aware it downloads zips, unpacks them, makes calls to unlink files, renames directories, and so on. I would recommend some caution, and especially, don’t run it as root - while developing it I had it extract a few zips to ‘/‘ or worse due to screwed up path logic. Equally, I would welcome a code review of the code in simgear/package/Install.cxx to check any security issues or dangerous behaviour. 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. — James Turner (2014-06-10). Re: [Flightgear-devel] select/download aircraft.
|
the 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.
— James Turner (2015-02-13). Re: [Flightgear-devel] FGDATA split without Aircraft. Addon in SVN.
(re)Suggesting a Submodule approach. (Re)Proposing a per-Aircraft
repository.
(powered by Instant-Cquotes) |
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.
— James Turner (2015-03-06). Re: [Flightgear-devel] FGData size reduction.
(powered by Instant-Cquotes) |
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.
— James Turner (2015-03-06). Re: [Flightgear-devel] FGData size reduction.
(powered by Instant-Cquotes) |
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. |