Today, I’ve played a bit with an idea to allow starting of YaST Server module from the YaST System Services module.

The only visible difference is the additional “Configure…’ button at the bottom of the dialog. This button would be active only if there is a YaST module associated with the entry. After clicking it, the respective YaST module would be started:

With this simple principle, the YaST control center ‘Network Services’ section would be reduced to:

And all those YaST modules would be available from ‘System’ section:

This approach could be used even further. You can see that the ‘Network Services’ section contents do not really match the section name anymore. In fact, most of the items could be moved to other modules as well. E.g. introducing a module for authentication/authorization, which would cover Kerberos client, LDAP client, etc. The NFS client is in fact a part of the new Disk Partitioning module already. So, the section could vaporize completely.

However, there are drawbacks. The biggest one I see is a ‘starting point’ problem. Just imagine you want to have a Apache2 running in your system. Until now, the YaST HTTP module is installed and can be used to bootstrap your configuration – it will install the packages and help to set up the basics. But with the new approach, the apache2 package is not installed, therefore System Services module would not see the apache2 service (init script) and does not show it at all! I’m not sure how to address this. Maybe the best would be to attach the YaST  module to apache2 package or HTTP server pattern and the Software Management module would become such starting point. Would it be better? I don’t know.

Then, there is an issue of a quick access – if you are moderately experienced user, you know what you are looking for and you start a proper module right away. But to figure out what is the configuration starting point if it’s hidden in another module, that might be a blocker.

I’m sure there are more problems. Anyway, I find the idea quite useful for reducing the number of YaST modules. What do you think?

YaST is one of the cornerstones of openSUSE. It is developed for openSUSE and is released as part of openSUSE. There never was a release of YaST independent of openSUSE. Even the versioning of YaST is tied to openSUSE – the versions are 2.X.Y, where X is increased for every openSUSE release (17 for 11.1) and Y is simply a patch level, whenever a new fix or feature is added. Even more, every YaST package has its own versioning, so the only way to ensure you have a consistent set of YaST packages is via dependencies set in the .spec file of the YaST packages.

But in principle, YaST is a tool that can be used across distributions and there are people interested in this to happen. There are technical barriers to do releases independent of openSUSE (e.g. a lot of openSUSE-specific knowledge and behavior coded in YaST) as well as procedural. During past years, a lot of these non-technical issues has been addressed as we opened up the YaST development (re-licensing the code under GPL, opening up source control system and mailing lists, etc).

But still, there is one big thing left: YaST packages are released in concert with openSUSE. Yes, it is very convenient for openSUSE, but it makes it almost impossible to track the development during for people outside of our great distribution.

If one looks at the way the YaST packages are updated during the hotphase of an openSUSE release, the core parts of YaST (yast2-devtools, yast2-core, libyui, …) are rarely updated, they get a bug fix here and there. However, the distribution specific parts (yast2-pkg-bindings, yast2 common libraries, bootloader, storage, networking, …) get a fast flow of patch-level releases, typically several between openSUSE milestones.

Thus, the way forward I like the most right now is a compromise: a core YaST system should be released independently of the openSUSE release cycle while specific modules could keep their crescendo during openSUSE hot phase. How to do that?

For core YaST packages (a list to be defined) would be released independently of openSUSE and during hot phase, they would be handled the way other FOSS parts of openSUSE are – by patching the code in the package. The rest of the YaST, current practice would stay untouched.

There are clearly advantages – the YaST developers can do a proper release management of the core code and it is much more predictable how the core part of YaST will be released. On the other hand, people would need to be aware of the split.

However, I can imagine there is a lot of I did not realize. I’m definitely interested in comments about this topic.