Flatpak Support

Similarly, and drawing on the same body of work as how we converted Baserock, we will want a script which reads a Flatpak project (which is normally a single JSON file in a directory, with some additional patches, scripts and other files lying around) and outputs a BuildStream project.

Some additional research will need to be done at this point to ensure we properly understand how extension points work, and how Flatpak Builder separates the data which goes into the .Locale and .Debug deployments.

Artifact Splitting

The result of any element's build is an installation of files which that build created. However it is interesting to categorize build output in an automated way, and with some options for users to override how output is classified.

We should be able to classify which files in an artifact are:

• Required for the software to run, usually binary or scripts, and configuration
• Required for development purposes, usually header files, static libraries
• Debugging symbols stripped from binaries
• Documentation

This data should be included as a first class citizen as it can be useful for other deployments, we should have public data in the "bst" domain which elements may override for this purpose.

Note that some consideration for files which are not included in a build's output but may be created by an element's integration-commands, font caches and the like, should be taken into consideration, as we already have a history of doing this the wrong way

Status: Done

This was done a while back, portions of artifacts can be staged by an element using the split-rules public data, this is already consumed by the compose element.

Flatpak Metadata Element

A large part of what goes into a Flatpak SDK, Runtime or App is metadata which just needs to be added to the ostree sysroot so that later, Flatpak itself will know what to do with it at runtime.

This should be a very simple Element to write, and will just require the user add some configuration which they normally place either into their metadata.in files, or to their builder JSON files, and have the Element output the appropriate metadata in the sandbox to be collected and staged.

Status: TODO

Write the conversion script

Here we'll have to examine all of the Flatpak Builder features and ensure we have our bases covered. For Flatpak builds which include patches and scripts, we need only convert those to buildstream local sources and add pre-configure-commands to the corresponding elements.

Of course this will also involve generating the compose elements and Flatpak metadata elements accordingly.

Note: It may prove to be a little more complicated to automatically convert the SDKs and Runtimes, mostly due to their respective makefiles and the metadata.in files found there, which are a non-issue for Apps. In this case, it is much less important to fully automate the runtime build conversions, as these will have to just be converted once and maintainership handed over to the GNOME release team and other parties. For the Apps however, we want to be able to transparently integrate with the Flathub project as it takes shape, and it should be straight forward to do for the various Flatpak App authors.

Status: TODO

Document migration process

This should again come in the form of a README found in the flatpak JSON converter repository. However we are very hopeful that there will be absolutely no human intervention needed to convert, as the Flatpak builder's build topology resembles that of buildstream closely enough, even though it is a serialized build model.

Status: TODO