Manifest: Smaller tweaks

[olof-nord]

This PR builds on top of https://github.com/flathub/com.tutanota.Tutanota/pull/152 - once that is merged the diff is more manageable.

Each change is split up into its own commit.

1. app-id is renamed to id
2. most of the finish-arg accesses are commented (yay to yaml)
3. tweak the archive unpacking, and move the unpacked archive directly to the install location
4. Update paths used when installing to reference FLATPAK_DEST as well as update the zypak-wrapper starting path.

Each change is kept as close as possible to the old JSON manifest as to avoid noise.

[flathubbot]

Started test build 87835

[flathubbot]

Build 87835 successful To test this build, install it from the testing repository:

flatpak install --user https://dl.flathub.org/build-repo/70502/com.tutanota.Tutanota.flatpakref

[charlag]

Hey, we had to roll back the yaml change for now because we generate the json file at the moment in a script and we need to adjust the generator too.

[olof-nord]

Alright, you decide. Why do you want to generate the manifest? Any chance of using standard flatpak tooling (see https://github.com/flatpak/flatpak-builder-tools/)

Note that there are tools to auto update the source git hash and file name - see https://github.com/flathub/flatpak-external-data-checker

Perhaps you could document how to modify the manifest generation when adjusting for example permissions (see the open bugs)?

[charlag]

You can have a look at what generate.bash does: https://github.com/flathub/com.tutanota.Tutanota/blob/master/generate.bash

manifest-template.js also updates the link used for build and I don't think the tools can do that?

[olof-nord]

I understand you are invested into your own custom tooling, it looks like it basically abstracts the whole flatpak tooling.

The data checker can from what I can tell automatically prepare pull requests for version changes both for the manifest checksum and file name, but also the appdata version.

Looking at many other flathub appdata/metainfo, we could probably save us the direct download link. See here for example: https://github.com/flathub/org.chromium.Chromium/blob/master/org.chromium.Chromium.metainfo.xml#L28

See an example automatic version update pull request here: https://github.com/flathub/com.skype.Client/pull/224

I would invite you to evaluate using common tooling both to attract contributors as well as avoiding reinventing the wheel.

[charlag]

Hey, we did not invent this wheel, we inherited it from whoever set up the initial flatpak build and adapted it to make sure it works with prebuild artifacts afterwards.

Thank you for the pointer to https://github.com/flathub-infra/flatpak-external-data-checker, we might get back to it but for now I'd say it's not a priority to change a build script that works.