Classic confinement for app-outlet


App Outlet is an application thas aim to put together Snaps, Flatpaks and AppImages.

We just want to be able to run CLI commands like ´snap install app-outlet´ or ´flatpak install flathub com.spotify.Client´.

So the users will be able to install packages using App Outlet interface.

Github link:
Latest release:


Do you need more information about the package?
Is my request under evaluation?


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.


With how many upvotes, the permission is given?


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 …


That may have been the policy, but other snaps exist which use snapd-control in the global store.

alan@KinkPad-K450:~$ snap connections snap-store | grep contr
snapd-control             snap-store:snapd-control             :snapd-control   

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?


Hello guys. @alexmurray, @ogra, @pedronis

There’s some update about my request?


Two points for context:

  • 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…)