FlightGear package manager

This article is a stub. You can help the wiki by expanding it.

Work in progress This article or section will be worked on in the upcoming hours or days. See history for the latest developments.

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)