Package management based on SFS mega-packages

EasyOS has two package management systems. At the top of the screen are icons labeled "petget" and "sfsget".

The former is a derivative of the traditional PPM (Puppy Package Manager, or Pet Package Manager), which can install and uninstall PET packages, as well as those of other distros, such as DEB packages.

sfsget is a downloader and "installer" for SFS files. These have a long history from the early days of Puppy Linux, back around 2005. They are mega-packages, that are loaded as layers using aufs or overlayfs (and unionfs in the early days).

SFS files have some tremendous advantages, including extreme ease of installing and removing -- they are just a single file, that is included in the layered-filesystem to install, and simply removed to uninstall. Really, these were the first "universal apps", before others like Flatpak and Snaps got the limelight!

Well, not quite "universal". A SFS file was created in a particular release of Puppy Linux, and designed to work on top of the base-SFS -- which in Easy is named 'q.sfs'. In a nutshell, Puppy/Easy run with a layered filesystem with the base-SFS at the bottom, extra SFS mega-packages above, and the read-write layer on top.

In the case of EasyOS, you can read about these layers here:

http://bkhome.org/easy/how-easy-works-part-2.html

One of my long-term goals with Easy is to make SFS files truly "universal". That is, you can download 'chromium-1,2,3.sfs' and it will "just work". Regardless of what version of Easy you are currently running. So, you could have an old favorite SFS, and continue to use it indefinitely.

What makes this scenario possible is containers, which was really "step 1", implementing Easy Containers. Now that is starting to look pretty solid, can move onto the proposed universal packages.

Like PET packages, SFS packages will have a one-line database entry, one field of which will state dependencies. For SFS, the deps will be SFS files. The deps field will have one entry, like this

...|+q&ge1.2,+devx&ge1.2|...

...the first entry states the version of q.sfs required, which could be an exact version (&eq), or greater-than (&ge), less-than, or a range. This is the same syntax as used in the traditional Puppy database format. Most SFS files will be complete and will only require the one dep, a q.sfs file.

The SFS file and its dep(s) SFS file(s) can be loaded in a container, and will "just work". This is independent of whatever version Easy is currently running -- you can keep updating Easy to later versions, which essentially means newer q.sfs and kernel, and it does not affect the containers. You can chroot into an old container, and it will still work.

...with some caveats, such as kernel version compatibility.

The entire concept is extremely simple and easy to manage. What I am investigating now, is how to store these SFS files online, in the ibiblio.org repository. Incidentally, down-the-track, this will be an opportunity for users to get involved -- user-created SFS files can be uploaded to the repo.

Another thing that I am thinking about is any special files that will need to be in an SFS file. For example, an equivalent of the 'pet.specs' file in PET packages. PETs also have a 'pinstall.sh' (post install) script, and the SFS might need an equivalent.

As they say, "the devil is in the details", but will get there!

SFS-based pups

The idea of creating a minimal Puppy and expanding it with SFS files, has a long history. This is before containers of course. One thing about the history of Puppy, is there has been so much creativity. Individuals have been inspired, though of course it has often happened that great innovations have lapsed.

Certainly worth a look, to see what has happened in the past. Links to the creations of some developers, such as 'jrb', 'RSH' (also known as 'Lazy Puppy', 'R-S-H', etc.) and 'wanderer':

ChoicePup: http://murga-linux.com/puppy/viewtopic.php?t=40569
Lazy Puppy: http://www.murga-linux.com/puppy/viewtopic.php?t=107208
Minimalist base: http://murga-linux.com/puppy/viewtopic.php?t=101461
corepup: http://www.murga-linux.com/puppy/viewtopic.php?t=108188

I downloaded jrb's ChoicePup, only 63MB, hey, a blast from the past! Works on my midi-tower. 

I browsed through these forum threads, as thought there might be some nice ideas in there.

Earlier universal packages blog posts

I have posted some earlier thoughts about implementing universal packages:

http://bkhome.org/news/201806/applying-the-kiss-principle-to-universal-packages.html
http://bkhome.org/news/201806/easyos-and-quirky-development-hiatus.html

Very quickly went off using Flatpak. I also went off the idea of creating universal packages from the binary packages of another distro (was considering Devuan). However, my universal packages, though designed to run on Easy, could also run on other distros, they will need to setup layered containers with the Easy SFS deps, such as q.sfs.

Flatpaks

Apart from the massive dependencies required for Flatpak, the complexity and the enormous sizes, I examined the underlying sandbox mechanism and was worried that it seems a bit "light weight" in the security department. This is an interesting read:

http://flatkill.org/ 

Of course, it is easy to snipe at another project. My experience with Flatpaks is brief, and I am sure it does have some merit!

Tags: easy