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.
Both comments and pings are currently closed.
Just exactly who will be responsible for the cross threading of YAST plus any criticism that this will generate. Getting other distros to work together has been one of the areas that Linux sorely lacks in. The mentality of I created this and mine is better than yours has always been one factor of any consolidation into one major operating system within the Linux complex. Could one imagine what could be created if some of the major players put their heads together and created a cross platform using the best of each and joined in furthering a major operating system.
Plus one factor is we would not want YAST to become a development nightmare like KDE has become. One of the major problems with Linux is a new user becoming familiar with the file management system. People coming into Linux from the other system are not use to having files in different areas and are use to them being consolidated under one program. This is not a easy task for them to learn and having a program like YAST would improve the attraction to Linux operating system and SUSE. Once they learn what YAST does and its ease of use it should generate interest from outside of SUSE.
Onestly i really disagree, YaST is one of the best suse points, without it, suse will lost lot’s of users, in the same way, yast code is available, and everybody is able to take and work on it…
I am looking at this from the perspective of improving linux as a whole – sharing code and having less reinventing of the wheel, etc. That being the case, I think it is a good thing for all linux users to have access to YaST. Opening up YaST like this could eventually mean more people working on making YaST better. This, in turn, could theoretically allow openSUSE developers to apply their creativity in additional areas.
Already, I have some crazy hopes for where this could lead.
I wonder if KDE and/or GNOME could end up using YaST code for their configuration GUI.
I wonder if YaST could become the default administration tool for several distributions.
If KDE/GNOME used YaST for their admin needs, I wonder if a distribution could integrate their YaST code with the KDE/GNOME YaST code to form one powerful, well integrated, admin tool.
Nathan
Tools like system-config-printer from Fedora is being used by Ubuntu and Mandriva while nobody except SUSE uses Yast. You got to think why.
Those two are unable to develop something better (integrated into their distro) than system-config-printer?
Yes, but why? Because system-config-printer is simple, user friendly, modular and importantly, doesn’t have distribution specific code splattered all over the place.