https://bugzilla.suse.com/show_bug.cgi?id=1175457 https://bugzilla.suse.com/show_bug.cgi?id=1175457#c11 --- Comment #11 from Stefan Hundhammer <shundhammer@suse.com> --- So, the data for that old RPM groups view are going away; while some RPMs might still contain them, they might be outdated. That was the reasoning for removing that view from the YaST package selector. I would gladly add another view with similarly useful browsing capabilities to YaST (the Qt version would be pretty easy, the NCurses version a bit more challenging - as usual. But we don't seem to have the data; this is the major problem. Maybe it would help to concentrate more on the actual use case: A user wants to find software for a specific purpose. I think we can safely exclude the gazillion of library packages from that; also the -devel or -doc packages that are mostly byproducts of creating a binary RPM, mostly library packages. As a user, when I need a libary, I know its name; I don't causually browse libaries to consider which of them I could also install. That leaves packages with user applications; on the level of desktop applications as well as shell commands. So that would apply to every package with a .desktop file and every package that installs a binary to /bin or /usr/bin. That reduces the amount of packages by quite a lot. The .desktop files already contain quite a lot of useful information (even with translations!); they have to provide a category for the menu tree in the desktop environment as well as the MIME types that they can handle. Both are interesting for a user browsing packages. Packages without a .desktop file, but with a binary in /bin or /usr/bin are a bit more challenging. But they should contain a man page which could be used to get information from. So, while we are building RPMs, couldn't we use that information to create more meta data in our repo files? Or maybe add that information to the RPMs (not sure what exactly the RPM format provides in that regard). Once we have that kind of data, we could use it to build a keyword index in the YaST package selector; in the case of desktop applications, we could even build the menu tree and let the user browse through that. I do understand the pain of a user trying to get useful information about the packages that we ship. We should not leave that to coincidence, i.e. to whatever Google chooses to put into their index database, or some bloggers who choose to blog about useful Linux applications. It should be us who provide that information; after all, we as a Linux distributor are the authority on that, not random bloggers. Of course, this would be something for a future release, not anything that we can realistically backport to released versions like SLE-15 SP2. -- You are receiving this mail because: You are on the CC list for the bug.