Testing vs Stable

In Calculate Linux 14 and earlier, all binary updates were stored in a single Git repository, whatever the flavour. Packages were thus updated at the same time as the Portage and overlays master branch was. Back then, as very few hosting platforms allowed automatic modifications, we only used two physical mirrors (the second one was for backup). It was not a good solution in terms of reliability, as well as for testing purposes. In fact, we could only test packages when building them; binary packages were not accessible. I fear we were not very fast in releasing new versions.

Important news of Calculate Linux 15 is that the update mirrors are now Git tagged, so that to allow synchronisation of Portage and the overlays with the mirror, thus increasing the number of mirrors unlimitedly. The latest versions are loaded onto the mirrors from the internal server. Any binary package can be tested, you can even rebuild the system with it before actually making it available.

Yet this does not seem reliable enough. Take a recent case of kernel update with default XZ compression, unsupported by our 32 bit kernels. As the new release was tested on 64 bit hardware only, it took us some time to realise that something was wrong, and the situation got worse as we updated Portage, pulling in up-to-date Chromium and LibreOffice versions, both of which are pretty heavy. It was comforting to know that the CL updater, unless you tell it expressly to do so, never deletes the previous kernel. One could boot from it while the problem was being fixed.

Some time back, we had asked our users on social networks whether they would like us to introduce test delay for packages. The results were surprising: the majority voted for a longer testing period. We even asked twice to make sure! But the solution, simple as it is, did not come immediately.

Now, all tests will be performed on ftp://ftp.calculate-linux.org/testing, our new server in Saint-Petersburg with rather fast connection speed both in Russia and Europe. All updates will be stocked there at first as they arrive. Some twenty-four hours after the testing mirror was last updated, it will be synchronised with the main repository. The latter, in its turn, will feed any other mirrors.

To be more precise, updates are, from now on, built on the internal FTP source at daytime. At night, they are loaded onto the testing mirror. If no bug is tracked during 24h, the update will be validated, otherwise another 24 hours after the problem is solved will be necessary.

It is up to you to decide whether you want testing or stable updates. If installing Calculate on a friend’s computer, running it at work or in an context that requires perfect security, don’t be ashamed to go stable. Otherwise, if you are a natural geek or just curious, you are probably more likely to choose testing.

stable_updates.png

To try the testing branch, please uncheck “Stable updates” in your Calculate Updater (make sure you got the latest version), or pass the --stable=off option to cl-update if you prefer the command line.

Minor modifications were also made, such as moving the mirror selector to the Main options. Note that the server url is always shown when you launch an update.

update_server.png

For the next version of Calculate Utilities, we expect to rewrite the algorithm for calculating the update time that would prevent from otherwise using the mirror when it is being updated. Up to now, this problem was temporarily resolved by comparing the several ini.env files created in different directories of the binary repo. When we have implemented the new layout, ini.env will include temporary Packages tags, to be matched.