Planning for flatpak 1.10

[Alexander Larsson]

On Mon, 2020-08-24 at 13:23 +0200, Bastien Nocera wrote:
> On Mon, 2020-08-24 at 13:08 +0200, Alexander Larsson wrote:
> > On Mon, 2020-08-24 at 12:27 +0200, Bastien Nocera wrote:
> > > On Mon, 2020-08-24 at 11:47 +0200, Alexander Larsson wrote:
> > > > 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 don't think flatpak does any git call-out, those are all in
> > flatpak-
> > builder i believe. However, fixing that is kinda tricky. If you
> > specify
> > nothing it always expands it to master in the code, rather than
> > "pass
> > nothing for branch, and then see what you get". So while you can
> > change
> > the branch and handle non-master branches, its a bit more work to
> > handle non-master default in a good way. Also, the git code is less
> > than obvious as it does local mirroring and shallow pulls.
> 
> You don't have to "pass nothing for branch and see what you get" to
> get
> the default branch, you can use something like this to do it:
> https://gitlab.gnome.org/GNOME/jhbuild/-/commit/77192689d33d54a43289130c5d7edf85e89f9f3d
> 
> Though it's certainly more complicated if you can't rely on the tree
> being checked out to run that command.

Yeah. Although there might be similar commands that work on a remote
instead?

> It will be a necessary change as GitHub, GitLab and GNOME all are
> going
> to change the name of the default branch for new projects. See:
> https://discourse.gnome.org/t/rfc-default-to-main-branch-name-for-new-repos-in-gitlab-gnome-org/3948
> 
> > For ostree branches, we do default to "master" in some cases. I
> > guess
> > it might be interesting to see what we can do about that. However,
> > for
> > flathub we don't actually use master, but rather "stable" and
> > "beta".
> 
> 280 "master" references in the flatpak tree alone.

Yes, but that is probably overcounting quite a bit via the testsuites.
The problematic parts are in the app/ and common/ subdirs, and
basically boils down to:

CLI:
 * build-bundle: "master" is default ostree branch if branch not 
   specified. Should probably default to whatever is in the repo
   and fail if unspecified when there are several alernatives.
 * build-export: Default ostree branch name for created ref if none
   is specified. This is probably the hardest to change, as changing
   it can break build scripts and there are no great source of other
   branch name options at the time of build-export.
 * build-finish: --runtime and --sdk lets you change to a new runtime
   ref, and master is the default. Can probably use the branch name 
   of the old runtime/sdk as the default.
 * build-init --base uses "master" for default branch name. We could
   just look for any existing one ref instead.
 * build-sign: Default ostree branch for ref name, can instead just
   look for what is exists.

files:
 * Default branch from a flatpakref file if none listed is master.
   Not sure if we can change this without breaking existing deployed
   flatpakref files.

libflatpak:
  Master is default if branch arg is NULL for:
  * launching installed app
  * Looking up an installed ref
  * Looking up a remote ref
  * Installing a ref (with old API)
  * Update a ref (with old API)
  * Uninstall a ref (with old API)
  * Some comments and examples in docs
  I think these could probably just be changed to mean "whatever is
  installed/available if left out".

So, really, the only hard ones are "whats the default branch of a build
that didn't specify a branch (change breaks scripts), and "whats the
default branch for a flatpakref file with not Branch=" key (change
break existing repos).

That said, having master in some places in the code is imho not as
important as avoiding it in the docs, ui or in any newly created
builds.

> I don't know whether "stable" or "beta" really reflect what that
> branch
> name is supposed to be, and there could be some benefits to not using
> either "master" or "main" which just ends up confusing developers
> that
> never quite get whether we're talking of an ostree branch or a git
> one.

Flathub has approximate meanings for these (although the exact meaning
is left up to each maintainer). So, those probably not a good idea to
use for e.g. default build branchname as the build may not fit those
meanings. But yeah, "master" or "main" is probably also not a good
choice.

Maybe something like "default".