We moved the summer of code ideas, and other projects to the YaST/Research page. We would like to find all the experiments that are lying around in the tmp and experimental branches and put them together in that page so previous attempts and knowledge is not lost.
Some information on branding the installation is available on YaST/Tips#Branding_the_installation.
The first thing that caught my attention in the rpm world was package groups. It is a 4 deep level tree which has become pretty useless with time. They are also not consistent across rpm distributions. I agree that they are interesting metadata (because they contain keywords), but nothing you want to display in a user interface.
So I started to ask people around. Do you use the groups tree?. “YES” was the first reply. I was surprised. Were my initial guesses wrong?. “I use it to select the zzzAll group, which is the only way to select all packages”. Interesting point, any effort to change this should take that into account.
Luckily all the answers were the same. The famous “zzzAll” group was the only reason why people used that filter.
So when looking for a way to make that screen more easy to the eyes, PackageKit groups seemed like the way to go, as they are already in use in some applications.
That is how package groups looked like before:
After matching the rpm groups to PackageKit groups, this is the result. Easy.
Notice that “All packages” is still there. Also there is a recommended and suggested groups. The interesting thing is, that if you look at other applications, like Gnome PackageKit install, which is a braindead application (no features) compared to YaST, but still, now they look pretty consistent with each other:
Before you cry for your old 4 level deep tree, you can still reach the groups via search. Search will look into the groups field and also the generated keywords in the metadata (tags).
Now uses the sat solver APIs to query the solv files, which is much faster and we have transparent access to more attributes.