<div dir="ltr"><div dir="ltr">On Sun, Apr 25, 2021 at 10:04 PM Adriaan de Groot <<a href="mailto:groot@kde.org">groot@kde.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Friday, 23 April 2021 11:58:07 CEST Jonathan Riddell wrote:<br>
> KDE's All About the Apps Goal hopes to use modern methods of getting our<br>
> apps to users.<br>
<br>
Let's reboot this conversation and the discussion in the MR. I'll give it a <br>
shot:<br>
<br>
<br>
<br>
===<br>
The KDE community selected "All About the Apps" as one of its goals (https://<br>
<a href="http://kde.org/goals/" rel="noreferrer" target="_blank">kde.org/goals/</a>). Part of that goal is pushing new packaging formats (snaps, <br>
flats and appimages). Part of it is improving application metadata -- and <br>
showing that on <a href="http://apps.kde.org" rel="noreferrer" target="_blank">apps.kde.org</a>.<br>
<br>
When pushing new packaging formats, there's a big difference to "traditional" <br>
packaging where a source tarball is thrown-over-the-wall to distros, who then <br>
do their thing with it. New packaging formats (which coincidentally are all <br>
containerized) put the packaging description into the source repository, <br>
because the "target distro" is known, as part of that new format.<br>
<br>
Effectively, this means that individual apps can opt **in** to a new format by <br>
adding the snap, or flat, or appimage description files to the source <br>
repository. There are a couple of apps that have done this already.<br></blockquote><div><br></div><div>With regard to Flatpak files, even if an application does add a file to it's repository it still has to register this in the central register at <a href="https://invent.kde.org/packaging/flatpak-kde-applications">https://invent.kde.org/packaging/flatpak-kde-applications</a>. Those manifests that are not registered in the central register will not be built by the Binary Factory - and Flathub will only pick up manifests that are stored in their repositories from my understanding of how Flathub works.</div><div><br></div><div>In terms of Appimages, there is no standardised way of producing these at the moment, although this is beginning to take shape in the form of Craft handling this. It should be noted that Craft requires blueprints to be created, which have to be stored in the central repository for those at <a href="https://invent.kde.org/packaging/craft-blueprints-kde">https://invent.kde.org/packaging/craft-blueprints-kde</a>. Having these in the application repository is not supported.</div><div><br></div><div>Snaps are the only format under discussion here as far as I am aware.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
For apps that do this, and **also** are part of the Release Service -- er .. <br>
part of KDE Gear, making use of the release service -- there is a spot of <br>
friction: the release scripts bump versioning information in CMake, set tags, <br>
make tarballs for "traditional" over-the-wall packaging. The release scripts <br>
do **not** update the new format information.<br>
<br>
This MR adds one feature to the release script: for apps that have opted in to <br>
snap (by putting snap-info in the source respository) that use the release <br>
service, the version information is also bumped in the snap-info. (Again, <br>
requires the app to opt-in to snap, and also to opt-in to release service)<br>
===<br>
<br>
<br>
<br>
Is **that** what you're trying to achieve?<br>
<br>
[ade]</blockquote><div><br></div><div>Cheers,</div><div>Ben </div></div></div>