If Feren OS was to ever block Snaps, here’s how I’d want to go about doing it
--
WOAH THERE, BLOCKING SNAPS you say? No. Let me preface this by saying this, and putting this out clearly:
This isn’t being considered at all right now, and it’s rather just a Plan E, or something like that, in case it’s ever necessary to follow through with this idea in the future. Better to have it on the cards just in case than not. Let me also preface this by saying I have a rather unique approach to this idea that you haven’t seen used… against Snap and Flatpak… in any other distribution, yet (or at least I haven’t).
That’s not to say this is an entirely original idea. No, if you’re a Fedora GNOME fan, you might scream at the monitor a few times that some of the ideas I’m gonna present in this article are very Fedora-like. If you do, well, that is probably because I shamelessly used some of Fedora’s ideas here, but also extended their idea towards Snaps and Flatpaks as well as standard native packages.
The Store
Let me also get this out of the way right now: This idea NEEDS my (offline powered) Store idea to be realised first before it can really shine in its conceptualised execution. Yes, it’s ambitious, but hopefully with a bit of help from others (psst, foreshadowing for something in the future I’m planning on doing) it isn’t anywhere near impossible. I just really need to learn how to make websites actually look good and adaptive, and uh, decide on which Qt ‘Kit’ (or whatever you want to call Kirigami, MauiKit, etc.) to use for the Store idea when it is made a reality. (no but seriously I’m really wondering which one I should pick, here…)
This idea also takes a heavy emphasis on the expectation that users will get their applications from the Store, so sorry Terminal/Konsole users but you’re kinda out of luck here (unless you want to learn a new Terminal command if this becomes reality).
With that out of the way, here’s how the idea would be executed:
Application Sources in Store Settings
The first thing that needs to be done so that this idea can be executed well is of course provide a place where people can optionally turn on and off ‘Software Sources’, or as I’m calling them here ‘Application Sources’.
Now, as I said before, this concept I’m about to present here might look VERY familiar to Fedora users, but… here’s an idea for how a page in Store’s settings for managing Application Sources could look like:
Here’s how it’d function: (each switch would prompt for superuser privileges)
Snaps
ON: The Store’s own APT config file will be edited by Store to disable snapd blocking, and then snapd will be automatically added to the Store’s installation queue if not already in the queue or not already installed
OFF: If Snaps are installed, the user will be prompted that by turning this switch off [list of installed Snaps] will be uninstalled from the system. After the user confirms, or if there are no Snaps installed, the system will proceed to add ‘snapd’ to the removal queue and finally tweak the Store’s own APT config file to enable blocking of APT packages named ‘snapd’.
Flatpak (global switch)
ON: The Store’s own APT config file will be edited by Store to disable flatpak blocking, and then flatpak will be automatically added to the Store’s installation queue if not already in the queue or not already installed
OFF: If Flatpaks are installed, the user will be prompted that by turning this switch off [list of installed Flatpaks] will be uninstalled from the system. After the user confirms, or if there are no Flatpaks installed, the system will proceed to add ‘flatpak’ to the removal queue and finally tweak the Store’s own APT config file to enable blocking of APT packages named ‘flatpak’ (it’s only fair really).
Flatpak (‘Add a Flatpak Remote’)
Does what it says on the tin — this will open a prompt with the option to add Flathub, Elementary AppCenter (once they make a Flatpak repository for that), [insert any other important Flatpak Repositories in here] or manually enter a Flatpak repository.
Flatpak (‘Remove [insert repository’s name here]’)
Also does what it says on the tin — removes the repository associated with the remove button after final user confirmation. Removing a Flatpak repository will however add the applications they provide to the removal queue.
Other Application Sources
If you know Fedora’s 3rd-Party Repositories Manager, you know what this does. Flick on and off these switches to enable/disable the associated package repositories. Disabling the associated package repositories will also add the applications they provide to the removal queue, however, so be careful.
Either way, before you go blasting my eardrums about how bad an idea supplying switches to enable sources for users to then finally be able to install their software is for new users, I have another thing I need to mention that is an extension to this idea, and the other piece of the puzzle needed for the execution of this idea to go well…
Store Application Listings
Irregardless of whether or not you have the appropriate Application Sources enabled, the Store will always list the same amount of applications, even if they technically aren’t available because of the fact you do not have the sources providing them enabled.
Now, how will this affect application installations? Well…
Installing applications when they’re technically unavailable
To finish off this idea, when installing applications that are from sources that aren’t enabled, you’ll notice they still have an install button, however there’d be a key difference between available and ‘unavailable’ applications’ install buttons:
- An available application’s install button will say “Install”
- However a technically unavailable application’s install button will say “Install…”
Since I don’t really have any adequate Store designs to illustrate my idea with, I’m just going to post a screenshot below of how Fedora GNOME handles this:
As for when you try to install a program that isn’t ‘available’ due to a disabled source, the program will continue installation as normal, however the Application Source for said application will be treated as a dependency of sorts and appear in a “This application will also install the following items” confirmation dialog at the top, with “Application Source” as its description to make it clear it’s going to automatically add an application source.
The user can proceed to freely either stop installing that application altogether or continue installing and have that source be enabled in the process.
Terminal-only management
Finally, some ideas for the Terminal:
- Either command-not-found will state to go to the Store -> Settings -> Application Sources to toggle Snap or Flatpak on if trying to use either command when the tools are not installed
- or command-not-found will open the Store automatically to the page of the appropriate application source to quickly enable it (the first idea will be used if running as Root)
- or command-not-found will direct users to a quick Terminal command to disable or enable application sources from a single command (e.g.: something like ‘feren-store-sources --enable-flatpak’).
Conclusion
In conclusion, that’s the general conceptualised idea. If Feren OS was to ever block Snaps by default, it’d just be treated as if Snap’s just yet another optional software source used by applications in the Feren OS Store application. That way it should not cause too much, if any, damage to the ease of use of the Operating System for those who want to use applications exclusive to these package management programs and their package repositories.
It’s a win-win idea for everyone (or at least I hope it is): Those who want Snaps and Flatpaks can just install the software as they like right from the Store, just like any other native application, at any time… and those who do not want anything to do with Snaps and Flatpaks can just disable them, be conscious about what sources they are getting their applications from and be happy as well with the reassurance that as long as Snaps and Flatpaks are turned off in Store nothing that depends on them can be installed from outside the Store (excluding downloaded DEB files) until they are enabled again.
That being said, this is only an idea for now. None of this has been made reality… yet. Maybe this might be made a reality one day, though… or maybe these ideas might even get repurposed one day instead, even. Either way, who knows? It’s 2020 so yeah who knows...
Why does the concept involve blocking flatpak and snapd when their respective switches are off? One fairness, and two to prevent them from being installed ‘behind your back’ by a package update from any source (not picking on Canonical here since anyone could do it someday by making a transitional dummy package to a Flatpak, even) Let’s also not forget that there’s still some people in this world who don’t like Flatpak either, nevermind just disliking Snaps.
I’ll try to remember when making this reality to add a bit of code to DEB file handling to enable Snap Store (snapd) or Flatpak in the Store’s fashion if a DEB ever depends on those packages, by the way, so don’t worry about that. (just, uh, when I do make the Store idea a reality (fingers crossed) can a person please remind me to do that when I get around to working on DEBs support for it?)
