<div dir="ltr"><div class="gmail_extra">Hi,<br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Exactly what goes into each repo is completely up to the user to decide. He may have one repo per app, or<br>
multiple apps in one repo, depending on his usecase.<br>
 </blockquote><div><br></div><div>From a developer perspective having N apps in the same repo seems handy. However, for the end user store website, having 1 repo per app could help implement some functionalities:<br><br></div><div>- Calculate download stats from http server logs<br><br></div><div>- Require authentication to download from a repo (useful for app purchases)<br><br></div><div>- In case is required a manual supervision of the apps before they are published or updated in the main store (the repo is updated), isolate the reviewing process of different apps<br><br></div><div>- Make it easier to unpublish an app from the store<br><br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Another question is how isolated we want the builds to be. Do we run<br>
each build in a fresh VM, or do we rely on the sandboxing that<br>
flatpak-builder uses? I added a "--sandbox" argument to<br>
flatpak-builder which disallows you from specifying<br>
break-out-of-sandbox arguments, but the container approach is always<br>
less isolated than a full VM, but slower.<br></blockquote><div><br></div><div>Can flatpak apps be build inside docker containers? If so, maybe it would be a good idea to publish official flapak-builder-ARCH docker images for users to build their apps locally and for the official build machine.<br><br></div><div>Best regards,<br></div><div>Jorge<br><br></div><div><br><br></div></div><br></div></div>