Hello,
My name is Igor. I'm long-time contributor in Fedora and started recently to contribute to the openSUSE with focus on cross-distro collaboration. I'm also contributor to many upstream projects which includes RPM.
You can see my oSC19 talk here: https://events.opensuse.org/conferences/oSC19/program/proposals/2489
There are still few things which are different between Fedora and openSUSE spec files for rust packages, more specifically those are license header, Group tag and changelog. While license header and changelog things are not easy to fix, the Group one is.
In Fedora, we have removed all Group tags in F30: https://fedoraproject.org/wiki/Changes/Remove_Group_Tag
Groups are hard to choose (I would rather prefer to see some kind of tags), there is no check from RPM itself (it is basically free-form text field) and usually you can't put application into one group because they belong to multiple groups.
I spoke to a few people on the oSC and it seems that only YaST is using this information to generate UI. So it should be doable to change its representation which is not based on the Group tag.
Considering above, is there some process like Fedora Changes (https://fedoraproject.org/wiki/Changes/Policy) in openSUSE where I can propose this?
On Tuesday 2019-06-04 15:08, Igor Gnatenko wrote:
My name is Igor. I'm long-time contributor in Fedora [..] https://events.opensuse.org/conferences/oSC19/program/proposals/2489 [..] Groups are hard to choose [..]
You don't say. https://lists.opensuse.org/opensuse-factory/2018-05/msg00465.html https://lists.opensuse.org/opensuse-factory/2018-05/msg00518.html https://github.com/rpm-software-management/rpm/issues/632
On Tue, Jun 4, 2019 at 9:08 AM Igor Gnatenko ignatenkobrain@fedoraproject.org wrote:
Hello,
My name is Igor. I'm long-time contributor in Fedora and started recently to contribute to the openSUSE with focus on cross-distro collaboration. I'm also contributor to many upstream projects which includes RPM.
You can see my oSC19 talk here: https://events.opensuse.org/conferences/oSC19/program/proposals/2489
There are still few things which are different between Fedora and openSUSE spec files for rust packages, more specifically those are license header, Group tag and changelog. While license header and changelog things are not easy to fix, the Group one is.
In Fedora, we have removed all Group tags in F30: https://fedoraproject.org/wiki/Changes/Remove_Group_Tag
Groups are hard to choose (I would rather prefer to see some kind of tags), there is no check from RPM itself (it is basically free-form text field) and usually you can't put application into one group because they belong to multiple groups.
I'm actually not a fan of the fact Fedora doesn't use the Group tag. It's more or less a cop-out to not provide some kind of way to organize all the packages in some manner. The fact that Fedora is the *only* distro that doesn't use it speaks more to the fact that YUM historically did not expose a way to sort using that tag. DNF does, and frontends like dnfdragora can use it to sort.
I'd rather re-introduce a better formulated Group tag in Fedora, but that takes some time I don't have right now...
I spoke to a few people on the oSC and it seems that only YaST is using this information to generate UI. So it should be doable to change its representation which is not based on the Group tag.
Considering above, is there some process like Fedora Changes (https://fedoraproject.org/wiki/Changes/Policy) in openSUSE where I can propose this?
Basically the way to do this is break everything by making submit requests to delete it from everything, update the rpmlint policy to flip from requiring a Group tag to requiring it to be eliminated, and so on.
On 6/4/19 9:08 PM, Igor Gnatenko wrote:
Hello,
My name is Igor. I'm long-time contributor in Fedora and started recently to contribute to the openSUSE with focus on cross-distro collaboration. I'm also contributor to many upstream projects which includes RPM.
You can see my oSC19 talk here: https://events.opensuse.org/conferences/oSC19/program/proposals/2489
There are still few things which are different between Fedora and openSUSE spec files for rust packages, more specifically those are license header, Group tag and changelog. While license header and changelog things are not easy to fix, the Group one is.
In Fedora, we have removed all Group tags in F30: https://fedoraproject.org/wiki/Changes/Remove_Group_Tag
Groups are hard to choose (I would rather prefer to see some kind of tags), there is no check from RPM itself (it is basically free-form text field) and usually you can't put application into one group because they belong to multiple groups.
I spoke to a few people on the oSC and it seems that only YaST is using this information to generate UI. So it should be doable to change its representation which is not based on the Group tag.
Considering above, is there some process like Fedora Changes (https://fedoraproject.org/wiki/Changes/Policy) in openSUSE where I can propose this?
+1 from me
Igor Gnatenko píše v Út 04. 06. 2019 v 15:08 +0200:
Hello,
My name is Igor. I'm long-time contributor in Fedora and started recently to contribute to the openSUSE with focus on cross-distro collaboration. I'm also contributor to many upstream projects which includes RPM.
You can see my oSC19 talk here: https://events.opensuse.org/conferences/oSC19/program/proposals/2489
There are still few things which are different between Fedora and openSUSE spec files for rust packages, more specifically those are license header, Group tag and changelog. While license header and changelog things are not easy to fix, the Group one is.
In Fedora, we have removed all Group tags in F30: https://fedoraproject.org/wiki/Changes/Remove_Group_Tag
Groups are hard to choose (I would rather prefer to see some kind of tags), there is no check from RPM itself (it is basically free-form text field) and usually you can't put application into one group because they belong to multiple groups.
I spoke to a few people on the oSC and it seems that only YaST is using this information to generate UI. So it should be doable to change its representation which is not based on the Group tag.
Considering above, is there some process like Fedora Changes (https://fedoraproject.org/wiki/Changes/Policy) in openSUSE where I can propose this?
We are already in process of abandoning it. See the thread 'Killing Group tag in .spec files' on this ML.
In short I think we removed it now everywhere except the packagehub website [1]. @ismail could you give up some feedback if you guys are still relying on this?
When that gets solved we can kill it right away.
Cheers
Tom
[1] https://packagehub.suse.com/package-categories/archiving/
On Tue, Jun 04, Igor Gnatenko wrote:
Groups are hard to choose (I would rather prefer to see some kind of tags), there is no check from RPM itself (it is basically free-form text field) and usually you can't put application into one group because they belong to multiple groups.
If I look at the Group tags from openSUSE spec files: somebody copies a draft specfile, somebody has no idea, doesn't find the right group, whatever: many Group entries are wrong, useless or something similar, so from no benefit for users. So removing them would not really change the situation, so I'm in favour of it.
Thorsten
On Tuesday 2019-06-04 15:19, Thorsten Kukuk wrote:
On Tue, Jun 04, Igor Gnatenko wrote:
Groups are hard to choose (I would rather prefer to see some kind of tags), there is no check from RPM itself (it is basically free-form text field) and usually you can't put application into one group because they belong to multiple groups.
If I look at the Group tags from openSUSE spec files: somebody copies a draft specfile, somebody has no idea, doesn't find the right group, whatever: many Group entries are wrong, useless or something similar,
Most Group entries are actually right, good enough, or something similar.
I have to know. A bot sends me a mail about every openSUSE:Factory submit request, and I should be known as someone who jumps at metadata any time.
Hi,
Tiny followup on this. As there was no major pushback on this I've created request to have next release of spec-cleaner to drop the group tag if encountered: https://github.com/rpm-software-management/spec-cleaner/issues/256
Cheers
Tom
Q: Do I have to do anything? A: Nothing unless you want to, if you use spec-cleaner it will be auto removed.
Q: What about SLE and backporting to older releases? A: Packages without groups will generate RPMlint warning, but apart from that are okay for submission (again the group is not really visible to the end user).N�����r��y隊Z)z{.���r�+�맲��r��z�^�ˬz��N�(�֜��^� ޭ隊Z)z{.���r�+��0�����Ǩ�
Jan Engelhardt píše v Út 27. 08. 2019 v 09:46 +0200:
On Tuesday 2019-08-27 09:09, Tomas Chvatal wrote:
Tiny followup on this. As there was no major pushback
That's twisting reality quite a bit there.
Your lonely complain is not a major pushback...
TomN�����r��y隊Z)z{.���r�+�맲��r��z�^�ˬz��N�(�֜��^� ޭ隊Z)z{.���r�+��0�����Ǩ�
On Tuesday 2019-08-27 09:50, Tomas Chvatal wrote:
Jan Engelhardt píše v Út 27. 08. 2019 v 09:46 +0200:
On Tuesday 2019-08-27 09:09, Tomas Chvatal wrote:
Tiny followup on this. As there was no major pushback
That's twisting reality quite a bit there.
Your lonely complain is not a major pushback...
It must be said the proponents of removing it were _equally_ lonely.
On Tuesday 2019-08-27 10:23, Jan Engelhardt wrote:
On Tuesday 2019-08-27 09:50, Tomas Chvatal wrote:
Jan Engelhardt píše v Út 27. 08. 2019 v 09:46 +0200:
On Tuesday 2019-08-27 09:09, Tomas Chvatal wrote:
Tiny followup on this. As there was no major pushback
That's twisting reality quite a bit there.
Your lonely complain is not a major pushback...
[1] https://lists.opensuse.org/opensuse-factory/2018-05/msg00465.html [2] https://lists.opensuse.org/opensuse-factory/2018-05/msg00518.html [3] https://lists.opensuse.org/opensuse-factory/2018-05/msg00467.html [4] https://lists.opensuse.org/opensuse-factory/2019-06/msg00055.html
So two people want to get rid of Group tags. Most package maintainers give a literal fuck: For them, the field might as well _stay_, because removing is work, too, and luckily there's a crazy German keeping the Group line up to date for them anyway. Not to mention that proposal of his to repurpose the field as a more useful Tags line. So, based on the old credo "those who do, decide", I do not feel forcing Group: out in a scripted fashion makes a very good picture of the efforts put in. And that pisses me off.
Am 27.08.19 um 10:41 schrieb Jan Engelhardt:
On Tuesday 2019-08-27 10:23, Jan Engelhardt wrote:
On Tuesday 2019-08-27 09:50, Tomas Chvatal wrote:
Jan Engelhardt píše v Út 27. 08. 2019 v 09:46 +0200:
On Tuesday 2019-08-27 09:09, Tomas Chvatal wrote:
Tiny followup on this. As there was no major pushback
That's twisting reality quite a bit there.
Your lonely complain is not a major pushback...
[1] https://lists.opensuse.org/opensuse-factory/2018-05/msg00465.html [2] https://lists.opensuse.org/opensuse-factory/2018-05/msg00518.html [3] https://lists.opensuse.org/opensuse-factory/2018-05/msg00467.html [4] https://lists.opensuse.org/opensuse-factory/2019-06/msg00055.html
So two people want to get rid of Group tags. Most package maintainers give a literal fuck: For them, the field might as well _stay_, because removing is work, too, and luckily there's a crazy German keeping the Group line up to date for them anyway. Not to mention that proposal of his to repurpose the field as a more useful Tags line. So, based on the old credo "those who do, decide", I do not feel forcing Group: out in a scripted fashion makes a very good picture of the efforts put in. And that pisses me off.
I see your point. But I think we really should eliminate *the need* to have a group line. Because for many packages it's just BS. Can we meet there?
Greetings, Stephan
On Tuesday 2019-08-27 11:25, Stephan Kulow wrote:
luckily there's a German keeping the Group line up to date [..]. Not to mention that proposal of his to repurpose the field as a more useful Tags line. I do not feel forcing Group: out in a scripted fashion makes a very good picture of the efforts put in.
I see your point. But I think we really should eliminate *the need* to have a group line. Because for many packages it's just BS. Can we meet there?
That goal is already reached. The Group tag has not been considered mandatory by tooling for a while, I believe. There is only polishing left:
* rpmlint's warnings * the Specfile Guideline wiki page needs a touch-up to explicitly declare it as "optional"; right now it is unspecified.
Neither of these mandate active removal good Group lines.
On 8/27/19 1:20 PM, Jan Engelhardt wrote:
[...] The Group tag has not been considered mandatory by tooling for a while, I believe. There is only polishing left:
Also the output of 'rpm -qi' would look strange:
$ rpm -qi $PACKAGE | grep ^Group Group : Unspecified
Have a nice day, Berny
Am 28.08.19 um 09:38 schrieb Bernhard Voelker:
On 8/27/19 1:20 PM, Jan Engelhardt wrote:
[...] The Group tag has not been considered mandatory by tooling for a while, I believe. There is only polishing left:
Also the output of 'rpm -qi' would look strange:
$ rpm -qi $PACKAGE | grep ^Group Group : Unspecified
Sounds easy to patch in rpm
Greetings, Stephan
On Wed, Aug 28, 2019 at 7:51 AM Stephan Kulow coolo@suse.de wrote:
Am 28.08.19 um 09:38 schrieb Bernhard Voelker:
On 8/27/19 1:20 PM, Jan Engelhardt wrote:
[...] The Group tag has not been considered mandatory by tooling for a while, I believe. There is only polishing left:
Also the output of 'rpm -qi' would look strange:
$ rpm -qi $PACKAGE | grep ^Group Group : Unspecified
Sounds easy to patch in rpm
Unless it make it hide it iff it renders Unspecified and show up otherwise...
That said, Zypper and YaST currently sort and organize RPMs via the Group tag. What are you going to do about that? You're going to need a better way to render that view if all the RPMs suddenly become "Unspecified"...
-- 真実はいつも一つ！/ Always, there's only one truth!
On Wed, Aug 28, 2019 at 4:49 PM, Neal Gompa ngompa13@gmail.com wrote:
On Wed, Aug 28, 2019 at 7:51 AM Stephan Kulow coolo@suse.de wrote:
Am 28.08.19 um 09:38 schrieb Bernhard Voelker:
On 8/27/19 1:20 PM, Jan Engelhardt wrote:
[...] The Group tag has not been considered mandatory by tooling for a while, I believe. There is only
polishing
left:
Also the output of 'rpm -qi' would look strange:
$ rpm -qi $PACKAGE | grep ^Group Group : Unspecified
Sounds easy to patch in rpm
Unless it make it hide it iff it renders Unspecified and show up otherwise...
That said, Zypper and YaST currently sort and organize RPMs via the Group tag. What are you going to do about that? You're going to need a better way to render that view if all the RPMs suddenly become "Unspecified"...
Not the case for YaST anymore: https://github.com/libyui/libyui-qt-pkg/commit/e7709a7f9a52423316ea529f670c4... https://github.com/libyui/libyui-ncurses-pkg/commit/8f1e61b356cfec6e024e1685...
LCP [Stasiek] https://lcp.world
Am Dienstag, 27. August 2019, 11:25:19 CEST schrieb Stephan Kulow:
I see your point. But I think we really should eliminate *the need* to have a group line. Because for many packages it's just BS. Can we meet there?
+1
OTOH, I cannot see a good reason to *actively* *eliminate* the Group line either, other than throwing away good work of good people.
A thousand years ago, people incited the crusades, just because there were other people, that doesn't fit their expectations.
Folks, don't incite a crusade against Group lines, please. They will not hurt you.
Am 27.08.19 um 09:09 schrieb Tomas Chvatal:
Q: What about SLE and backporting to older releases? A: Packages without groups will generate RPMlint warning
Then please get a rpmlint update into SLE-{11,12,15}-{GA,SP{1,2,3,4}}. This is annoying as hell and creates support effort for many people.
Stefan Seyfried píše v Út 27. 08. 2019 v 10:02 +0200:
Am 27.08.19 um 09:09 schrieb Tomas Chvatal:
Q: What about SLE and backporting to older releases? A: Packages without groups will generate RPMlint warning
Then please get a rpmlint update into SLE-{11,12,15}- {GA,SP{1,2,3,4}}. This is annoying as hell and creates support effort for many people.
It is just SLE-12 (GA+SP1+SP2+SP3) and 15.
SLE11 I don't see any reason why that one should be done as it is under LTSS support for 2 months now.
The fix is oneliner so I don't see a reason why not release that really.
But honestly I don't consider it being too important. There are so many warnings there printed right now, with older codestreams even misleading... about update-alternatives/buildroot/clean...
Only tw lists around 14 000 warnings on something like 7000 packages, which means 2 per pkg... https://rpmlint.opensuse.org/
If it would be an Error then I agree we would need to release rpmlint updates prior the change, but like this it is mostly noop.
Tom
Am 27.08.19 um 09:09 schrieb Tomas Chvatal:
Hi,
Tiny followup on this. As there was no major pushback on this I've created request to have next release of spec-cleaner to drop the group tag if encountered: https://github.com/rpm-software-management/spec-cleaner/issues/256
SLES11 rpm chokes on missing group tag.
On Thu, Aug 29, 2019 at 4:52 AM Stefan Seyfried stefan.seyfried@googlemail.com wrote:
Am 27.08.19 um 09:09 schrieb Tomas Chvatal:
Hi,
Tiny followup on this. As there was no major pushback on this I've created request to have next release of spec-cleaner to drop the group tag if encountered: https://github.com/rpm-software-management/spec-cleaner/issues/256
SLES11 rpm chokes on missing group tag.
If you can convince SUSE to backport the following fixes to SLE 11's rpm package, that'd be amazing: * https://github.com/rpm-software-management/rpm/commit/c094de4d1017af3ffbe89f... * https://github.com/rpm-software-management/rpm/commit/6c0651926aedc302816a0b...
I just wish the issues with using stronger/better GPG keys wouldn't break rpm 4.4... I'm waiting patiently for the day that I can retire my weak RSA GPG key used for SLE 11 packages...
On 8/27/19 9:09 AM, Tomas Chvatal wrote:
Tiny followup on this. As there was no major pushback on this I've created request to have next release of spec-cleaner to drop the group tag if encountered: https://github.com/rpm-software-management/spec-cleaner/issues/256
(Are there) next steps?
Have a nice day, Berny
On Tuesday 2019-09-03 14:19, Bernhard Voelker wrote:
On 8/27/19 9:09 AM, Tomas Chvatal wrote:
Tiny followup on this. As there was no major pushback on this I've created request to have next release of spec-cleaner to drop the group tag if encountered: https://github.com/rpm-software-management/spec-cleaner/issues/256
(Are there) next steps?
Since yast2-sw_single no longer displays groups, I have now made a basic alternate program to bring back the functionality of a software catalogue browser that, like yast2_sw, reads the Group: field and presents a tree.
https://github.com/jengelh/rpm-catalog https://build.opensuse.org/package/show/home:jengelh:dev/rpm-catalog
This is meant to operate with a modern tag/category/keyword list, akin to SO tags, placed in the Group: field. The program equally eats the "Foo/Bar/Baz" groups of current packages.
Naturally, such a browser can only work if there is group/tag information to begin with.
On Tue, Sep 3, 2019 at 9:18 PM Jan Engelhardt jengelh@inai.de wrote:
On Tuesday 2019-09-03 14:19, Bernhard Voelker wrote:
On 8/27/19 9:09 AM, Tomas Chvatal wrote:
Tiny followup on this. As there was no major pushback on this I've created request to have next release of spec-cleaner to drop the group tag if encountered: https://github.com/rpm-software-management/spec-cleaner/issues/256
(Are there) next steps?
Since yast2-sw_single no longer displays groups, I have now made a basic alternate program to bring back the functionality of a software catalogue browser that, like yast2_sw, reads the Group: field and presents a tree.
https://github.com/jengelh/rpm-catalog https://build.opensuse.org/package/show/home:jengelh:dev/rpm-catalog
This is meant to operate with a modern tag/category/keyword list, akin to SO tags, placed in the Group: field. The program equally eats the "Foo/Bar/Baz" groups of current packages.
Naturally, such a browser can only work if there is group/tag information to begin with.
I'll just point out that your readme indicates that the Debian "Section" field lets you set multiple values. This is wrong. You can only set _one_ value, just like the Group tag in RPM. The "tags" you see in the Debian package search web UI only exist there and nowhere else. Fedora's tagger service did something similar, but it was equally pointless.
On 9/4/19 3:18 AM, Jan Engelhardt wrote:
Since yast2-sw_single no longer displays groups, I have now made a basic alternate program to bring back the functionality of a software catalogue browser that, like yast2_sw, reads the Group: field and presents a tree.
https://github.com/jengelh/rpm-catalog https://build.opensuse.org/package/show/home:jengelh:dev/rpm-catalog
This is meant to operate with a modern tag/category/keyword list, akin to SO tags, placed in the Group: field. The program equally eats the "Foo/Bar/Baz" groups of current packages.
Naturally, such a browser can only work if there is group/tag information to begin with.
IIUC that means that we don't have to remove the existing 'Group:' line from the spec files, right?
Thanks & have a nice day, Berny
On Wednesday 2019-09-04 08:44, Bernhard Voelker wrote:
On 9/4/19 3:18 AM, Jan Engelhardt wrote:
Since yast2-sw_single no longer displays groups, I have now made a basic alternate program to bring back the functionality of a software catalogue browser that, like yast2_sw, reads the Group: field and presents a tree.
https://github.com/jengelh/rpm-catalog https://build.opensuse.org/package/show/home:jengelh:dev/rpm-catalog
This is meant to operate with a modern tag/category/keyword list, akin to SO tags, placed in the Group: field. The program equally eats the "Foo/Bar/Baz" groups of current packages.
Naturally, such a browser can only work if there is group/tag information to begin with.
IIUC that means that we don't have to remove the existing 'Group:' line from the spec files, right?
There was never a time that you had to remove it.
On 9/4/19 11:23 AM, Jan Engelhardt wrote:
On Wednesday 2019-09-04 08:44, Bernhard Voelker wrote:
IIUC that means that we don't have to remove the existing 'Group:' line from the spec files, right?
There was never a time that you had to remove it.
... apart from $SUBJECT (and e.g. the Fedora link in the 1st post). ;-)
Thanks & have a nice day, Berny
-
Bernhard Voelker -
Hans-Peter Jansen -
Igor Gnatenko -
Jan Engelhardt -
Maurizio Galli (MauG) -
Neal Gompa -
Stasiek Michalski -
Stefan Seyfried -
Stephan Kulow -
Thorsten Kukuk -
Tomas Chvatal