site  contact  subhomenews

Thinking how to manage the Void rolling release model

January 19, 2024 — BarryK

I posted yesterday about liking how easyVoid has turned out:

https://bkhome.org/news/202401/easyvoid-is-looking-good.html

...Flapi, the Flatpak manager, is now working, and various other issues fixed, so now looking even better.

Version 6.0 will probably be released this weekend, but I have been thinking of strategies to play nicely with the Void rolling-release model. If you were to install Void itself, then there are no future release numbers; you just keep syncing with the latest packages. EasyVoid could do the same thing.

The "update" icon on the desktop could work in a new way. Clicking on it, could download the latest packages from the Void repository, and build new 'easy.sfs' and 'devx.sfs' files. There would then be a version-update based on these files.

What this would mean is that easyVoid users can update on their own. They will not have to wait for me to release a new version of easyVoid. Although I will be releasing version 6.0, after that the version numbers will be by date, in format year-month-day, for example 240318.

EasyVoid would work like EasyOS, /mnt/wkg/releases has a history of past versions, or in this case, dates. If you were to update from, say, 240228 to 240318, but find that things have gone bad -- which is always a risk with the rolling-release model, no problem, just reboot and choose to roll back to the previous version.

I won't have to be constantly working to release new versions. I could go off into the Outback on my trike, or even "fall off the perch" as my step-grandad used to say, and easyVoid users can just keep on updating.

The "update" icon can also be made to read a patch-file from somewhere, if any fixes to the 'initrd' or 'easy.sfs' are required. Then there is the requirement to update the kernel -- and currently easyVoid requires a different kernel from the official Void ones.

The devil is in the details of course. The most likely way to implement this is to have a "mini Woof" builtin to easyVoid, let's say at /usr/local/woofv -- yeah, call it "woofV".

The kernel, yeah, a problem. It uses aufs, whereas Void kernel only has overlayfs. EasyOS relies on a big kernel, with all drivers builtin to access drives and HID devices. My very limited exposure to Dracut, as used for the Void kernel, is not good. Possibly woofV could also compile the latest kernel, or we could have a repo where a small band of easyVoid users can upload stuff, such as kernels.

Anyway, this is all very interesting. easyVoid 6.0 will be released, and it will have to be considered as an "alpha" release, because of my very limited testing. Testers will be most welcome! I will apply fixes, and hopefully implement "woofV" and at some time not to far in the distance, release easyVoid stable, not as 6.1 but as a date, like 240228.    

Tags: easy