For the case of snaps - these could be installed instead by taking advantage of the snapd-control interface - however there is no similar interface for flatpak / AppImage - so at this stage classic makes the most sense. +1 from me.
while this is true, the snapd-control interface is exclusive to brand stores only, by store policy snaps using it will be blocked from uploads to the global store, so this is likely not an option here …
To enable app-outlet to “install” an AppImage, that’s effectively just downloading the .appimage file into ~/AppImages (or whatever) and marking executable. Launching it will be problematic from the app-outlet application, as it won’t be able to launch arbitrary executables.
For flatpak I think there needs to be an interface developed, as there’s more integration needed there.
While I appreciate classic might be a short term option as @alexmurray suggests, it’d be way cleaner and more re-usable (if other store app frontends come along) if an interface existed.
While it would be technically possible to install snaps in a confined snap using snapd-control (as the Snap Store snap does) it would not be possible to install/launch AppImages or flatpaks from a confined snap.
I am inclined to agree with @alexmurray that, at this time, classic confinement is required for app-outlet to function as a snap. +1 from me
yes, canonical owned snaps like the snap-store one have been the exception to this policy (though indeed it could have been changed recently)
i also remember that we in general used to not allow managers for other package formats into the store, not sure if that rule still stands … IIRC @niemeyer and/or @jdstrand established that rule a while back…
EDIT: i dug up an older reply about the package management topic:
@pedronis - there is a question on the general policy regarding package managers in the store - see @ogra’s comment above - can you comment on what the current status is for this, and whether it is appropriate to grant classic confinement for app-outlet as a result?
we have distinguished package managers for language libraries vs applications, the assumption with the former is different audience expectations
snap-store is confined strict
The issue with application package managers in the store is that all the policy/security questions that applies to single app snaps, here turn into meta questions. The security and policy picture gets fairly complicated.
Rarely but we had to unpublish snaps. What would/should be the response if a package manager features some malaware (not packaged as a snap) either by mistake or intentionally? To me it looks like a complicated situation for all parties involved.
(About strict snaps with snapd-control in the main store, the discussion over time afair is that it would be considered for large Open Source communities…)