Planning for flatpak 1.10

[Bastien Nocera]

On Mon, 2020-08-24 at 11:47 +0200, Alexander Larsson wrote:
> Last week I did I started doing some planning for Flatpak 1.10, with
> the goal of doing a release around the end of the year.
> 
> Feature-wise I think we're in a pretty good state, so there will not
> be
> a lot of feature work. Instead, the main work will be on repository
> scalability. Right now, the repository format is based on the summary
> file, which has to be downloaded in its entirety before doing
> anything. 
> 
> The summary contains information about all the refs in the repository
> including the app metadata (permissions, dependencies, etc) for each
> app. Additionally it contains all the delta files available in the
> repo. To make matters worse, all this info is duplicated for each
> supported architecture, making adding new arches very expensive.
> 
> So, some possible options we have here are:
>  * Some form of delta for summaries
>  * Split summaries in per-arch
>  * Move delta info out of the summary file
>  * Use more efficient summary format
> 
> Additionally, while we're redoing the summary and repo format we want
> to make sure to:
>  * Repository subseting (i.e. FSF free subset of flathub)
>  * Improve the download size estimates (for the non-delta case)
> 
> I also want to look at some minor features:
> 
> Explore the possibility of using cgroups v2 for per-app limits (cpu,
> memory, etc).
> 
> Explore the possibility of using slirp4netns to do network filtering.

Yes!

> Support debuginfod in flatpak/flathub to allow automatic on-demand
> debug info download. However, it is possible we can do this entirely
> without support from flatpak.
> 
> I also want need to make a pass over the terminal output/redraw
> handling in flatpak, as it needs some polish.

I think we will also need to look at making sure that we handle default
git branches that aren't called "master" (I believe in flatpak, and
flatpak-builder) and consider whether we want to also move the default
ostree repo default branch name.

I haven't filed issues for those, as I wanted to do a pass over the
codebase to assess, but I can do that if that's something that can get
looked over without my involvement ;)

Cheers