<div dir="ltr"><div dir="ltr">On Mon, Oct 26, 2020 at 4:07 AM Aleix Pol <<a href="mailto:aleixpol@kde.org">aleixpol@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 Sun, Oct 25, 2020 at 2:28 PM Volker Krause <<a href="mailto:vkrause@kde.org" target="_blank">vkrause@kde.org</a>> wrote:<br>
><br>
> Hi,<br>
><br>
> I've been looking into the F-Droid meta data generation a bit, now that I am<br>
> able to run this locally and make changes to it.<br>
><br>
> The current system with generating the meta data from the final APK on the<br>
> signing system is nice in that it is entirely transparent for the app, but it<br>
> does have a few limitations:<br>
> - it's happening late in the pipeline, which makes some information hard to<br>
> access (such as the source code repository URL)<br>
<br>
You might be right about that. The repository URL is something fiddly<br>
in any case because there's many approaches that don't build software<br>
from git (e.g. tarballs).<br>
<br>
I would like to include the git repository url in the appstream<br>
metadata for many reasons (de-duplication, development tools<br>
integration, etc.). This is something I could push for.<br>
That said, it might not solve the problem entirely.<br>
<br>
> - it's running on the signing system, which requires deploying updates<br>
> manually, and presumably doing things like screenshot downloads on there isn't<br>
> ideal either from a security POV either<br>
<br>
Yes, this was something that changed recently because Ben preferred to<br>
do it this way. I agree it's not ideal and again it's something we can<br>
probably improve upon by doing it closer to the developer setup.<br></blockquote><div><br></div><div>Please note that historically the metadata extraction process was always part of the F-Droid repository management tooling.</div><div>I only continued that approach - my change was to split the signing and repository management off from the Android builders to a dedicated isolated system to improve security.</div><div><br></div><div>I agree that it makes much more sense to have the build process produce a dedicated metadata file we can make use of, rather than us inferring it from a bunch of information contained within the APK.</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>
> - it's not able to make use of manually provided parts for the meta data (e.g.<br>
> the banner image which has no equivalent in appstream).<br>
<br>
True.<br>
We can have custom fields in appstream too, not sure if that is useful<br>
elsewhere.<br>
<br>
> - it's not accessible for F-Droid release builds, ie. builds running on their<br>
> infrastructure<br>
<br>
We can split the code outside, wherever makes sense.<br>
<br>
> A possible way to address this could be to move meta data generation from repo<br>
> generation to the build process, implemented as part of ECM. The resulting<br>
> meta data would then need to be transferred alongside the APKs to the signing<br>
> system for integration into the F-Droid repo, presumably this can be done by<br>
> the same mechanism as the APKs are transferred.<br>
><br>
> I think this can be done in a similarly transparent way, while now also being<br>
> able to implement merging existing meta data fragments from the source dir. By<br>
> moving to ECM this also becomes independent of our CI tooling, which should<br>
> help F-Droid release builds.<br>
><br>
> Thoughts?<br>
<br>
Overall I think it's good to make this process more reliable. I wonder<br>
what's the right way, the line between powerful and overengineered can<br>
be thin.<br>
ECM would be a fine place to put it. Also the AndroidExtras repository<br>
we keep talking about could be a place. Our toolchain already depends<br>
on Python so it shouldn't be entirely out of place.<br>
<br>
When you say "the same mechanism" you mean passing the metadata side<br>
by side or including the metadata within the apk?<br>
<br>
> @Nico: would that cover what F-Droid builds need?<br>
> @Aleix: could you add a license/copyright to the generation script (or provide<br>
> me with one) please, preferably with an ECM-compatible license?<br>
<br>
Sure, no problem.<br>
<a href="https://invent.kde.org/sysadmin/binary-factory-tooling/-/merge_requests/120" rel="noreferrer" target="_blank">https://invent.kde.org/sysadmin/binary-factory-tooling/-/merge_requests/120</a></blockquote><div><br></div><div>Cheers,</div><div>Ben </div></div></div>