Many years ago, we had the RPM Groups view (a tree) in the YaST Package Selector, and it was a useful method to go through all packages in a systematic way to see what’s available.
Then it was decided to drop it and to rely on patterns only, but patterns don’t offer nearly the same power as RPM groups. But many packages lost their RPM group tag since then, so the metadata have become incomplete. Still, many other packages still have it, and it can be useful at least for them.
With Myrlyn 0.9.8, the RPM Groups view is back (mostly because other distros asked for it). Is it useful for openSUSE users? Should we keep it, or get rid of it again?
(In any case, it will be available with a manual edit in the Myrlyn config file)
As this was many years ago, many will never have seen it. Plaese elaborate a bit more about what it is and what the advantages of it are.
That it is “systematic” seems logical to me, else it would have no place in computer software. But I fail to see the hierarchical structure of a tree of RPMs, other then the dependencies that look to me as a tree (package A needs B en C then B needs D, E and F and so on, well after thinking of it it might not be a tree, because F may need B).
You may want to have a look at the screenshot in the github discussion. There you can see the group view.
Some other distributions use the group view in their package managers. But i never really used it as i didn’t see an advantage.
Yes, seems to be an example. Looks as if packages are grouped by functionality. But there is one package there that describes itself as “Window manager” in the list of “Display managers”. Maybe that shows us a week point here. When packager are a bit loose in their group description, it soon becomes untrustworthy.
And of course there has to be a authority that defines which groups there are and their exact names.
Is it posible to have more then one (functionality) group assigned to a package? E.g Konqueror is a File manager and a Web browser.
It may turn out that searching through the package descriptions works better. But who knows.
There used to be a default tree defined by the RPM standard, but this implementation uses whatever the packages define: It iterates over all packages, gets the “RPM Group” tag from each one, and puts them into a tree that you can go through to see the packages by hierarchical categories.
No, only one tree branch per package as defined by the RPM standard.
I used to love Konqueror as a web browser back in the KDE 3 days, but later more and more web pages didn’t work anymore properly with it. The integration between web and desktop / local files was great.
@hcvv that was the reason RPM Groups was removed to allow the application meta data to provide that information instead and also desktop menu categories. So the onus on these descriptions is implemented upstream, rather than at a package level.
That, of course was not the point of my question (i still use Konqueror for showing man pages and some web-sites), but the question was if it’s dual functionality, as file manager and as webbrowser could be accomodated in this group system. And you say it is not possible. Not that it matters much, but I try to get a better view of what this feature is. For me and for all others that read this, but never saw it before.
And yes, the above answers give already a good idea what this is about.
You mentioned that, other distributions have asked for the RPM Groups view to be reinstated.
Does this mean that, currently, the RPM package maintainers are (mostly) consistently and, consequently, maintaining the “Group” tag on the packages they’re responsible for?
Henk has indicated an instance where, this isn’t the case …
Taking Malcolm’s point about the meta data, and presuming that, he means an application’s ‘.desktop’ file, yes, if the application has a GUI then, there’s quite a bit of useful information in there but, what if the application doesn’t have a GUI and, there ain’t nothing in the package which looks like a meta data file?
Then, there’s only the XML associated with the RPM package …
If, around about, 70 % or 80 % of the packages are as consequent as the Vim and LibreOffice folks then, it could make sense, for the “New User” Use Case, to keep the RPM Groups view in Myrlyn.
@dcurtisfra as a package maintainer I don’t want to see Groups added back to rpm spec files. The whole idea of the meta data is that applications like Discover, GNOME Software, Myrlnn can use this data to display the relevant information. Likewise *.desktop categories can be extracted (so less work for packagers, maintenance of rpm macros) to populate the correct groups in the DE Menu systems.
It’s still in the .spec file for those packages that kept it, like “gimp” here:
Group: Productivity/Graphics/Bitmap Editors
Some SUSE packages still have it, some don’t.
That had been my reason why I was reluctant at first to reintroduce this view (see issue #111), and why I did those tests in issue #112 to check how many packages still have a group, and how many don’t; and why I finally started this discussion.
In the GitHub issue #112, there are almost seven thousand (7 000) packages listed as being “unspecified” in the Myrlyn screenshot …
And, as you mentioned in the GitHub discussion, KDE doesn’t supply any RPM Group information – please note that, KDE Discover executes quite happily without any RPM Group information.
If, the KDE packages no longer provide any Group information in the RPM tags then, that’s quite a major reason to not support it in openSUSE Myrlyn instances …
At least for those user’s who’re using KDE Plasma as their Desktop Environment.
Or, you could provide a Myrlyn option to disable the RPM Group view if, the DE is KDE Plasma …
Like others have mentioned, I’ve never really used the RPM Groups feature myself. From my perspective it would be more consistent to leave it out. That said, a reasonable middle ground might be to keep the RPM Groups view available as an optional feature in Myrlyn (e.g. a config toggle button), so those who find it useful can enable it without affecting everyone else.
The grouped view by groups or categories is a good way to explore what software comes with the distribution. It’s similar to what’s done here in Discover/Software or here.
I don’t know the implementation details and assume it was removed eventually for some reason.
But there’s no point in doubting its usefulness, as long as it’s done well.
BTW: I’ve changed your KDE Apps language from “es” to “en” …
And, this KDE Apps view is possibly more informative: <Categories - KDE Applications>
Yes, but, it may well be the, those web sites are based on RPM Groups but, as explained above, the KDE Plasma packages no longer supply any RPM Group information.
It may well be that, providing a Myrlyn view similar to that provided by the KDE Plasma “Categories” might be a good idea but, how?
At least for the case of KDE Plasma, we may well have to simply point to the KDE Applications “Categories” web page.
