There are heretic movements being made right now to actively kill the Group line, rendering software like rpm-catalog useless to the end-user. Not to mention it nullifies the 3000 or whatever SRs made within the last 2 years, which is a great way to say "thank you, for nothing".
So I advocate that Group lines must be retained if they exist and are updated.
On Fri, 2019-10-04 at 13:10 +0200, Jan Engelhardt wrote:
There are heretic movements being made right now to actively kill the Group line, rendering software like rpm-catalog useless to the end-user. Not to mention it nullifies the 3000 or whatever SRs made within the last 2 years, which is a great way to say "thank you, for nothing".
The Group tag is a useless thing - you yourself advocated to replace it with a Tag-based system, not a tree-like system.
but yes, RPM should be patched to simply not show it when it's not defined - there is no value in this field.
So I advocate that Group lines must be retained if they exist and are updated.
Disagree - Cleaning up and being consistent is better here. Does not mean that your work is not valued - but hey: plenty of packages I did 15 years ago have been dropped by now. such is life - and evolution keeps on moving.
Cheers, Dominique
Am 04.10.19 um 13:18 schrieb Dominique Leuenberger / DimStar:
On Fri, 2019-10-04 at 13:10 +0200, Jan Engelhardt wrote:
There are heretic movements being made right now to actively kill the Group line, rendering software like rpm-catalog useless to the end-user. Not to mention it nullifies the 3000 or whatever SRs made within the last 2 years, which is a great way to say "thank you, for nothing".
The Group tag is a useless thing - you yourself advocated to replace it with a Tag-based system, not a tree-like system.
but yes, RPM should be patched to simply not show it when it's not defined - there is no value in this field.
So I advocate that Group lines must be retained if they exist and are updated.
Disagree - Cleaning up and being consistent is better here. Does not mean that your work is not valued - but hey: plenty of packages I did 15 years ago have been dropped by now. such is life - and evolution keeps on moving.
I followed the discussion previously but not in detail. I have to say that my typical workflow after a fresh installation is to go through the package manager to install what I want and need.
And btw. I'm using the Group view for that because the others or even more useless IMHO. So if we remove Group what is the proper replacement? Patterns are not a solution for me because I feel those are missing too many packages I need. What else?
Wolfgang
On Fri, 2019-10-04 at 13:26 +0200, Wolfgang Rosenauer wrote:
Disagree - Cleaning up and being consistent is better here. Does not mean that your work is not valued - but hey: plenty of packages I did 15 years ago have been dropped by now. such is life - and evolution keeps on moving.
I followed the discussion previously but not in detail. I have to say that my typical workflow after a fresh installation is to go through the package manager to install what I want and need.
You seem to refer to the 'Package Grous' view? Frankly, I can't even say how this is populated - but it is clearly not the tree-like structure we have in the Group Tag. There is for example a group 'GNOME Desktop' - but you won't find this string in any RPM Group tag.
Cheers, Dominique
Am 04.10.19 um 13:34 schrieb Dominique Leuenberger / DimStar:
On Fri, 2019-10-04 at 13:26 +0200, Wolfgang Rosenauer wrote:
Disagree - Cleaning up and being consistent is better here. Does not mean that your work is not valued - but hey: plenty of packages I did 15 years ago have been dropped by now. such is life - and evolution keeps on moving.
I followed the discussion previously but not in detail. I have to say that my typical workflow after a fresh installation is to go through the package manager to install what I want and need.
You seem to refer to the 'Package Grous' view? Frankly, I can't even say how this is populated - but it is clearly not the tree-like structure we have in the Group Tag. There is for example a group 'GNOME Desktop' - but you won't find this string in any RPM Group tag.
So seems I'm late. I cannot tell when it changed but it used to be a tree structure. Probably even still in 15.0 but indeed not anymore with 15.1. So my usecase is broken already probably in preparation of getting rid of the Group tags :-(((
Wolfgang
Am 04.10.19 um 13:34 schrieb Dominique Leuenberger / DimStar:
On Fri, 2019-10-04 at 13:26 +0200, Wolfgang Rosenauer wrote:
Disagree - Cleaning up and being consistent is better here. Does not mean that your work is not valued - but hey: plenty of packages I did 15 years ago have been dropped by now. such is life - and evolution keeps on moving.
I followed the discussion previously but not in detail. I have to say that my typical workflow after a fresh installation is to go through the package manager to install what I want and need.
You seem to refer to the 'Package Grous' view? Frankly, I can't even say how this is populated - but it is clearly not the tree-like structure we have in the Group Tag. There is for example a group 'GNOME Desktop' - but you won't find this string in any RPM Group tag.
The view appears to be loosely based on the Group tag. The mentioned 'GNOME Desktop' seems to consist of exactly the packages in System/GUI/GNOME. Many groups are aggregated in this view, for example all Development/*/* categories appear together, and under Education we have Productivity/Scientific/* together with Amusements/Teaching/*. At least that is what my cursory observations suggest, I didn't find anything about it in the YaST sources.
While the Group tag might not be perfect, dropping it seems premature, especially in cases where it is correct. In my personal experience it makes software easier to discover, especially software that one might not even be aware of. Incorrect categories don't remove much of that benefit as long as most packages are still correct. Dropping the tag should be discussed when there is a (better) replacement.
Making the Group tag optional in rpm (with a default value like Uncategorized if we need it) like you suggested elsewhere is still worth discussing, since no tag isn't worse than a wrong one. Changes like Jan's that fix (or then add) the Group tag should still be welcome though, I think.
Best regards, Aaron
On 2019-10-06 23:54, Aaron Puchert wrote:
While the Group tag might not be perfect, dropping it seems premature, especially in cases where it is correct. In my personal experience it makes software easier to discover, especially software that one might not even be aware of. Incorrect categories don't remove much of that benefit as long as most packages are still correct. Dropping the tag should be discussed when there is a (better) replacement.
I didn't follow the whole discussion from the beginning, but it seems that the problem is that a package can be logically belong to one or more groups, while the RPM Group tag (probably?) allows only the assignment to one Group, right? Furthermore, the only value out of Groups is to present some searchable structure in an installer.
Looking around, I have to say I like the grouping the Cygwin installer uses: a package can be found there in several groups, which seems fully okay.
Have a nice day, Berny
On 04/10/2019 13.26, Wolfgang Rosenauer wrote:
Am 04.10.19 um 13:18 schrieb Dominique Leuenberger / DimStar:
On Fri, 2019-10-04 at 13:10 +0200, Jan Engelhardt wrote:
I followed the discussion previously but not in detail. I have to say that my typical workflow after a fresh installation is to go through the package manager to install what I want and need.
And btw. I'm using the Group view for that because the others or even more useless IMHO. So if we remove Group what is the proper replacement? Patterns are not a solution for me because I feel those are missing too many packages I need. What else?
I also use the Group view. I find it useful. No idea where it comes from, though.
Just saying :-)
On Friday 2019-10-04 13:18, Dominique Leuenberger / DimStar wrote:
On Fri, 2019-10-04 at 13:10 +0200, Jan Engelhardt wrote:
There are heretic movements being made right now to actively kill the Group line, rendering software like rpm-catalog useless to the end-user. Not to mention it nullifies the 3000 or whatever SRs made within the last 2 years, which is a great way to say "thank you, for nothing".
The Group tag is a useless thing - you yourself advocated to replace it with a Tag-based system, not a tree-like system.
But I have also shown that the current tree-ish values make a good figure as tags already.
I hope you can understand that, with all the "remove, remove!" atmosphere, there is hesitation to begin deployment of the current group lines with the tag system if the outlook is such that the line gets removed afterwards anyway.
Basically, distro-wide changes are harder to make than ever, and SR approval by many entities is just one factor. With that, distros bring (can bring) ever less Added Value to the table. That, in turn, leads to the self-erosion, or actually, self-abolishment of a distro ("Die Distro schafft sich selbst ab") as it can no longer stand out.
On Fri, Oct 04, Jan Engelhardt wrote:
There are heretic movements being made right now to actively kill the Group line, rendering software like rpm-catalog useless to the end-user. Not to mention it nullifies the 3000 or whatever SRs made within the last 2 years, which is a great way to say "thank you, for nothing".
We had this discussion already and we disagreed, but again: the current list of groups is pretty useless and many packages have wrong group tags, even if you claim otherwise. Why? Because for many important areas we have no matching group at all.
Or can you tell me, where you would look for all the container or kubernetes related tools?
Not even the wiki page is correct. It claims you can introduce new groups by just using them. But of course, we don't allow that, there is somewhere a list which creates an error and the reviewer will reject the package.
So, if you want to have RPM Group Tags, make at first sure, that the "infrastructure" is correct, documented and working including processes to adjust the list, that we have useful current groups (not what was usefull 10-15 years ago) and that people really choose a good group.
The current mess is not needed.
Thorsten
On Friday 2019-10-04 14:50, Thorsten Kukuk wrote:
On Fri, Oct 04, Jan Engelhardt wrote:
There are heretic movements being made right now to actively kill the Group line, rendering software like rpm-catalog useless to the end-user. Not to mention it nullifies the 3000 or whatever SRs made within the last 2 years, which is a great way to say "thank you, for nothing".
many packages have wrong group tags
That is quite vague.
Why? Because for many important areas we have no matching group at all.
Or can you tell me, where you would look for all the container or kubernetes related tools?
Virtualization methinks. This, upon now checking, also happens to be where docker et al are sorted in freshcode.club. The "old-style" RPM group seems to be System/Emulators, which is where most of the important stuff like dosbox (emulator), virtualbox (not so much an emulator), and wine (not an emulator at all) is. I can imagine why the container people put it under System/Management; it's not an emulator and it can be used to "manage" a system, though that grouping is vague in itself; some people even consider their container stuff System/Base probably, just because it's a kernel feature.
The upside is: It can be fixed in short order. Like any bug, being aware of the existence is the first, and most important, part of it.
Not even the wiki page is correct. It claims you can introduce new groups by just using them. But of course, we don't allow that, there is somewhere a list which creates an error
"somewhere"... more of the vagueness :(
First, it did not generate an error, it generated a warning. Second, rpmlint does not even generate a warning anymore.
On Fri, Oct 04, Jan Engelhardt wrote:
On Friday 2019-10-04 14:50, Thorsten Kukuk wrote:
On Fri, Oct 04, Jan Engelhardt wrote:
There are heretic movements being made right now to actively kill the Group line, rendering software like rpm-catalog useless to the end-user. Not to mention it nullifies the 3000 or whatever SRs made within the last 2 years, which is a great way to say "thank you, for nothing".
many packages have wrong group tags
That is quite vague.
Do you really think somebody will paste for you the hundred or thousands packages with wrong groups? I brought an example, should be enough.
Why? Because for many important areas we have no matching group at all.
Or can you tell me, where you would look for all the container or kubernetes related tools?
Virtualization methinks.
If we put everything into Virtualization we don't need groups. Has the same affect as no group at all. But your answer only proves, that the current Group list is unuseable.
Not even the wiki page is correct. It claims you can introduce new groups by just using them. But of course, we don't allow that, there is somewhere a list which creates an error
"somewhere"... more of the vagueness :(
If you make sure the packaging guidelines are everywhere correct, we can speak about exact locations. As long as the wiki has no or wrong informations, yes, this is "vagueness". As long as only a few people like you knows the details, you don't need to wonder if people are vague or ignore it. And no, I will not reverse engineer your tools.
First, it did not generate an error, it generated a warning. Second, rpmlint does not even generate a warning anymore.
Most interesting part: why did you delete the other part? Because they are correct and you cannot put them away in a non-constructive way?
Thorsten
On Friday 2019-10-04 15:52, Thorsten Kukuk wrote:
many packages have wrong group tags
That is quite vague.
Do you really think somebody will paste for you the hundred or thousands packages with wrong groups? I brought an example, should be enough.
One wrong group does not make thousands wrong. If there really were _that many_ wrong associations, that would have been noticable during opensuse:Factory reviews, of which there are about 5200 per month. I do not remember seeing you doing, or being subscribed to, factory review requests, so I do not think your claim that there is a thousandfold wrong groups holds water.
Why? Because for many important areas we have no matching group at all.
Or can you tell me, where you would look for all the container or kubernetes related tools?
Virtualization methinks.
If we put everything into Virtualization we don't need groups.
Well you need Virtualization as a tag/group to distinguish it from all the Amusements (Games) that the distro also is shipping.
First, it did not generate an error, it generated a warning. Second, rpmlint does not even generate a warning anymore.
Most interesting part: why did you delete the other part? Because they are correct and you cannot put them away in a non-constructive way?
I wanted to save you from an embarrasment that you did not do your homework:
So, if you want to have RPM Group Tags, make at first sure, that the "infrastructure" is correct, documented
The infrastructure is correct now; RPM groups are no longer validated since 2019-09-26. I also believe the wiki page was in accordance with the infrastructure at the time the page was edited (2016-11-20) - and I have just tested that theory too now.
Branching a package from 42.2 (release date 2016-11-16) and 42.3 (next release after 2016-11-20), I changed the Group to mumblejumble and let OBS do its build with the subsequent rpmlint run. In those build results, rpmlint does NOT complain of an invalid group.
Therefore the wiki was accurate until someone else changed rpmlint without updating the docs.
A cursory look into openSUSE:Factory/rpmlint reveals that group validation seems to have been added in r282, dated 2017-10-18.
So please, cut me some fucking slack already.
Am Freitag, 4. Oktober 2019, 13:10:16 CEST schrieb Jan Engelhardt:
There are heretic movements being made right now to actively kill the Group line, rendering software like rpm-catalog useless to the end-user. Not to mention it nullifies the 3000 or whatever SRs made within the last 2 years, which is a great way to say "thank you, for nothing".
So I advocate that Group lines must be retained if they exist and are updated.
Obviously, spec-cleaner actively removes them already, and there exist some packaging committee, that decided to do so (according to Matej Cepl in a PM).
Oh well, Pete
On Wednesday 2019-10-16 16:49, Hans-Peter Jansen wrote:
Am Freitag, 4. Oktober 2019, 13:10:16 CEST schrieb Jan Engelhardt:
There are heretic movements being made right now to actively kill the Group line, rendering software like rpm-catalog useless to the end-user. Not to mention it nullifies the 3000 or whatever SRs made within the last 2 years, which is a great way to say "thank you, for nothing".
So I advocate that Group lines must be retained if they exist and are updated.
Obviously, spec-cleaner actively removes them already, and there exist some packaging committee, that decided to do so (according to Matej Cepl in a PM).
|MC: """That’s just spec-cleaner running. And the discussion on the list was |completely non-sensical (as I wrote there), because it was discussing which |has been already long time decided by the packaging committee."""
Hold on, I smell bullshit and a coup d'etat. What is this committee? Where does it come from? Who is on it? What gave them legitimization? There is but a single fucking mention of it on the wiki. In other words, it's thin air.
openSUSE, how low can you go?
-
Aaron Puchert -
Bernhard Voelker -
Carlos E. R. -
Dominique Leuenberger / DimStar -
Hans-Peter Jansen -
Jan Engelhardt -
Thorsten Kukuk -
Wolfgang Rosenauer