As promised in the previous post on this blog, we’ll try to keep you updated about what is happening in the YaST world. Before Christmas we finished an specially short sprint, interrupted by another successful Hackweek. Although we always reserve some time for bug fixing, the last two sprints has been quite focused in looking into the future, implementing new solutions for old problems and trying to prepare replacements for some legacy stuff we have been carrying on for too long. Here you are the highlights.
SCR replacement
For low level access to the system, YaST uses its own library called SCR, inherited from the old YCP days. It’s used to call scripts and also to read and write files. Its design is showing its age and using it from Ruby is unnecessary complex. We feel SCR is one of the biggest source of confusion for newcomers to YaST development. Last but not least, SCR is only used by YaST which means all the maintenance work fall to us.
We want to use a new approach for the future. For running scripts we plan to use a Ruby gem called Cheetah and for accessing configuration files we plan to rely on Augeas.
Taking some improvements that were needed in YaST2-Bootloader and the drop of perl-bootloader as starting points (or as an excuse, if you prefer), we have used this sprint to develop all the moving parts that will allow us to easily use Cheetah and Augeas within YaST.
For Cheetah, we have contributed two features to the upstream project: chroot support and the ability to provide environment variables.
For Augeas we have developed an object oriented layer called Config Files Api (shortly CFA). The idea of CFA is to provide specific functionality by mean of plugins. Of course, the first plugin we have developed is aimed to manipulation of all the Grub2 configuration files.
The next step will be to integrate these new components into the next versions of YaST2-Bootloader, hitting your Tumbleweed repositories soon. Of course, after all the usual manual and openQA testing.
Libstorage replacement
Another low level layer that has been a constant source of headache for YaST developers is libstorage. We use it -specially in the installer and the partitioner- to access disks, partitions, volumes and all that. Once again, the original design have fundamental flaws that limit us in many ways and we have been dreaming for quite some time about writing a replacement for it.
To make this rewrite fit into the Scrum process, we are using the new redesigned library (find the code at Github and the packages at OBS) to write prototypes for the installer partitioning proposal and for a new partitioning YaST module.
This new module is only intended as a testbed to showcase the development of the new library and to drive its integration process. It’s not intended for end users, but after this sprint it can already do some things that are impossible with the current partitioner and even shows some nice graphs really useful for debugging and verifying the behavior of the library.
If you don’t mind to break your system using unsupported software, you can always fetch the code or the packages.
AutoYaST integration tests
Testing is crucial in software development. And integration tests are a must when you are developing an installer. During the last sprints, we have been developing and improving our own solution for testing AutoYaST-driven installations, consisting on a set of tests and a framework to run them.
The goal for this sprint was to de-couple the tests and the framework. Making it possible to reuse our tests in openQA. As a side effect, we wanted to ease the installation and usage of our testing framework.
Both goals were achieved, now you can install AutoYaST Integration Tests (not a very original name) following the instructions available in the repository and there is already an openQA instance directly running the separately available tests.
Snapper development documentation
Last but not least, as a side effect of the development (and the Scrum principles), we have improved the Snapper’s development documentation. Enjoy it at the usual Snapper repository.
That’s all folks. Next sprint starts next week and will be three weeks long, so expect more news during the first days of February.
