site  news  contact

Package manager concepts

August 05, 2023 — BarryK

Page created: April 3, 2023
Updated: April 8, 2023. June 11, 2023. August 5, 2023

This page is an overview of packages and package managers; what are the choices, how do the packages install, how do you use them, how to remove.

To install or remove a package, click the "pkg" icon on the desktop:


This brings up a window offering a choice:


...yes, EasyOS has not just one package manager; Easy has four different package managers:


This is the traditional package manager. Packages are tarballs, of various formats, such as .pet, .tar.xz, .deb, .rpm. These install directly at "/" in the main-filesystem.


These are large apps, or many apps, in a read-only file, that is mounted as a layer in the layered filesystem, either in the main-filesystem or in a container.


These are also large apps, in a read-only file. They are intended to be Linux-distribution-independent, with all dependencies builtin. They run in the main-filesystem, but not installed like traditional packages.
Flatpaks are also large Linux-distribution-independent applications, with all dependencies builtin. They also run in the main-filesystem, but not installed like traditional packages.

A key concept in EasyOS is that the "main-filesystem" is created by layers, like this:

this is the abstraction, view at the top
RW layer folder
this is the .session folder in the working-partition
RO layer folder
optional extra sfs file, for example devx.sfs
RO layer folder
easy.sfs is mounted on this folder

Containers are also built with layers, looking just like the above. Here is a visualization of how the four package managers install:

img1 is all very well seeing pretty diagrams, as they are supposed to make everything clearer. One thing that the above diagram doesn't really explain, is how the SFS, AppImage and Flatpaks are actually installed, compared with traditional packages.

So, another pretty diagram. This one shows where those three types of package get downloaded to:

img10, they are actually installed into the working-partition, and menu-entries, symlinks, etc., created to make then available in the main-filesystem or, in the case of SFSs alternatively available in a container.

To find the app you want, you do need to become familiar with what is in all four package managers. The example is given of OBS Studio as an SFS file, but in EasyOS Kirkstone-series it is also in PKGget, the traditional package manager. In theory, OBS could also be provided as an AppImage or a Flatpak.

So, explore. If you have a choice, say OBS in PKGget or SFSget, it is helpful to have an appreciation of the advantages and disadvantages of each. Here are some notes, firstly concerning security:



These packages install directly at "/" in the main-filesystem. By default, the installed app will run as the 'root' user, so this is the least secure. However, it is possible afterward, to change to run as non-root user; see the menu "System -> Login & Security Manager".*


These mount either as a layer in the main-filesystem, or in a container. In the former case, the app will run as the root user or non-root, depending on how the SFS was created. In the latter case, the app will run as "crippled root" and in some cases as user "spot".**


These all default to run as a non-root user in the main-filesystem.
Flatpaks run as a non-root user in the main-filesystem. They have a builtin sandbox, so inherently more secure than AppImages.

Or, click on the "kirkstone" icon and the entire EasyOS will run in a container. This is very secure "crippled root" and PKGget will work in this environment.
Or, run EasyOS in a QEMU VM. Still running as root, but isolated.

The Author is creating most SFS apps to run non-root, except those that are best as the root user, such as the "devx" SFS

Here is part of the "Login & Security Manager" window, in the Author's currently-running system:


...Chromium and hexchat are actually in easy.sfs. The others are AppImages or Flatpacks. Apps installed non-root run as separate unique users, for maximum isolation. Each app has its own home folder, as seen in the Author's recent system:

img3 is not just superior security; this isolation is also good from an organization viewpoint; the data of each app is completely separate from others.

So, security of an app running non-root on the main filesystem is excellent, approaching that of running in a container. So take your pick.

So what about ease of updating and removal? Here is a table from that perspective:

Updating & Removal


The versions are fixed, until the repository is updated. PKGget is able to install and remove. In some cases, an app has its own update feature.


These are also fixed versions. If the app has an update feature, that will work. SFS files are a single file, and very easy to uninstall, just by removing the file. However, it is recommended to uninstall via the menu "Filesystem -> Easy BootManager" so as to remove menu entry, etc.


As the AppImage file is just one file, uninstall is quite easy, just delete it; you will find it at /mnt/wkg/appimage. However, to get rid of the the menu entry and link from /usr/bin, the easiest way is to choose uninstall in Appi.
AppImages have serious problems with updating; if the app offers to update, decline, as it in a read-only file. Appi is able to probe for a latest version, though it is not guaranteed to work, see explanation here.
Flatpaks support updating, that you can do via Flapi (the Flatpak Installer). Flapi can also uninstall.

Finally, thinking about general usage and usability:

General usage


No real problems, except that most of them default to run as root, which some users object to (but see * above).
These have the highest level of compatibility with the host system, as they were compiled to link against all the exact same libraries as in the host.


If install to the main filesystem, a reboot is required before can use it, due to it being a layer in the filesystem. In a container, is available immediately.
The disadvantage in a container is that the app may be noticeably slower to start and run.
Some SFS apps work on the main-filesystem, but not in a container, due to the more severe security restrictions.


These work well, start and run fast.
As they default to run as a non-root user, they can only open and save files in their home folder, or under /files
A bit slow to startup. Downloads and updates are massive; you need a fast Internet connection with generous data allowance. The sandbox can be a pain if you need to circumvent it.

The above tables are generalizations. More details could be added, but then it becomes a trade-off; too much detail causing confusion. So, advice is to just use the four packages managers, explore.

Here are some links for further reading:

Further information





As well as the overall conceptual "How Easy Works" pages:

Have fun!   

Tags: user