[opensuse-factory] Killing Group tag in .spec files
Hi all, We have pretty strict requirements how the group tags are shown. [0] But there are only 2 ways to use it, 1) yast view based on groups 2) using rpm -q to get information for the individual package. For all other purposes from zypp/packagekit this stuff is ignored. In general it does not really make sense to install packages based on groups. As Fedora already deprecated this tag it would make sense for us to drop it too [1][2]. Proposed change would be to kill the Yast UI and then have spec-cleaner to drop the part where needed. It won't break on older releases as it would simply have Undefined as a group. Cheers Tom [0] https://en.opensuse.org/openSUSE:Package_group_guidelines [1] https://fedoraproject.org/wiki/Packaging:Guidelines#Tags_and_Sectio ns [2] https://fedoraproject.org/wiki/RPMGroups
On Tuesday 2018-05-29 12:45, Tomas Chvatal wrote:
But there are only 2 ways to use it, 1) yast view based on groups [...] In general it does not really make sense to install packages based on groups.
It was not so much about installation, but exploration in related software. (To me, anyway.) The grouping made yast something of a "Things to Explore" guide to the packages it had. It made me install and learn about the roxen webserver once upon a time. With the high group memberships numbers today (Languages/Haskell alone for example is 2000+ pkgs) - not to mention the terrible package descriptions that usually go along with it - the yast group view certainly feels more like a telephone book than a curated guide. So yeah, I concur Group: has outlived its usefulness in openSUSE for the reason just provided. (Now, the only thing left is Debian getting rid of *their* "Section:" tags ;-) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, 2018-05-29 at 13:17 +0200, Jan Engelhardt wrote:
On Tuesday 2018-05-29 12:45, Tomas Chvatal wrote:
But there are only 2 ways to use it, 1) yast view based on groups [...] In general it does not really make sense to install packages based on groups.
It was not so much about installation, but exploration in related software. (To me, anyway.) The grouping made yast something of a "Things to Explore" guide to the packages it had. It made me install and learn about the roxen webserver once upon a time.
+1
With the high group memberships numbers today (Languages/Haskell alone for example is 2000+ pkgs) - not to mention the terrible package descriptions that usually go along with it - the yast group view certainly feels more like a telephone book than a curated guide.
Ah yeah, you remind me that I wanted to discuss with the Haskell team if we can make the rpm Group tags better somehow. -Scott
Am 30.05.2018 um 09:07 schrieb Scott Bahling:
On Tue, 2018-05-29 at 13:17 +0200, Jan Engelhardt wrote:
On Tuesday 2018-05-29 12:45, Tomas Chvatal wrote:
But there are only 2 ways to use it, 1) yast view based on groups [...] In general it does not really make sense to install packages based on groups.
It was not so much about installation, but exploration in related software. (To me, anyway.) The grouping made yast something of a "Things to Explore" guide to the packages it had. It made me install and learn about the roxen webserver once upon a time.
+1
Actually the Group index in YaST is what I use _every time_ I install a system. I'm always annoyed by wrong or inconsistent tags though but now I understand that many people do not really care. :-( Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wednesday 2018-05-30 10:50, Wolfgang Rosenauer wrote:
It was not so much about installation, but exploration in related software.
Actually the Group index in YaST is what I use _every time_ I install a system. I'm always annoyed by wrong or inconsistent tags though but now I understand that many people do not really care. :-(
Luckily, there's at least one person that cares about trying to fix a mismatching Group: field once so spotted :) Which group(s) do you "+"-select in yast when installing a system? I just find it hard to believe anyone would literally install *all* the pieces from CPAN that found their way into openSUSE. Just considering the ACME::* subspace of Perl, not even cboltz is bold enough to have installed all of them at the same time. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi, Am 30.05.2018 um 11:10 schrieb Jan Engelhardt:
On Wednesday 2018-05-30 10:50, Wolfgang Rosenauer wrote:
It was not so much about installation, but exploration in related software.
Actually the Group index in YaST is what I use _every time_ I install a system. I'm always annoyed by wrong or inconsistent tags though but now I understand that many people do not really care. :-(
Luckily, there's at least one person that cares about trying to fix a mismatching Group: field once so spotted :)
I did so as well but not for every case. Feels like DonQuichote.
Which group(s) do you "+"-select in yast when installing a system? I just find it hard to believe anyone would literally install *all* the pieces from CPAN that found their way into openSUSE. Just considering the ACME::* subspace of Perl, not even cboltz is bold enough to have installed all of them at the same time.
I do not select whole groups. But I use the group index to find software I might be interested in. That is totally not the case for libraries or perl modules since those hopefully are pulled in by dependencies. But for applications or server daemons I use this index to select certain packages. Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wednesday 2018-05-30 09:07, Scott Bahling wrote:
On Tue, 2018-05-29 at 13:17 +0200, Jan Engelhardt wrote:
On Tuesday 2018-05-29 12:45, Tomas Chvatal wrote:
But there are only 2 ways to use it, 1) yast view based on groups [...] In general it does not really make sense to install packages based on groups.
It was not so much about installation, but exploration in related software. (To me, anyway.)[...] With the high group memberships numbers today (Languages/Haskell alone for example is 2000+ pkgs) - not to mention the terrible package descriptions that usually go along with it - the yast group view certainly feels more like a telephone book than a curated guide.
Ah yeah, you remind me that I wanted to discuss with the Haskell team if we can make the rpm Group tags better somehow.
I looked at the Package Hub page you pointed to, and was surprised to notice myself finding that I would totally want to retain RPM groups for games, while *anything* from development is totally explore-un-worthy to me. I recognize it's all about "getting something done" vs "getting entertained". Desktop themes would be another thing that falls in the second one and therefore benefits from grouping like games. Maybe this insight helps in finding where to go :) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2018-05-30, 07:07 GMT, Scott Bahling wrote:
With the high group memberships numbers today (Languages/Haskell alone for example is 2000+ pkgs) - not to mention the terrible package descriptions that usually go along with it - the yast group view certainly feels more like a telephone book than a curated guide.
Ah yeah, you remind me that I wanted to discuss with the Haskell team if we can make the rpm Group tags better somehow.
It's déjà vu all over again. This is exactly the discussion
I have experienced couple of years on Fedora lists. Let me
enumerate the steps:
1. Somebody asks “What is the Group field for? Does anybody
use it?”
2. “Groups are such mess, that almost nobody uses them.”
3. So, let’s fix them! Current situation when half of our
packages are thrown into Text/Processing is crazy
4.
On Wednesday 2018-05-30 16:24, Matěj Cepl wrote:
Ah yeah, you remind me that I wanted to discuss with the Haskell team if we can make the rpm Group tags better somehow.
It's déjà vu all over again. This is exactly the discussion I have experienced couple of years on Fedora lists. Let me enumerate the steps:
5. It’s crazy, how can I classify everything when selecting from 1200 groups? Why is one text stream processing tool (sed) System/Base and other (python2-html2text) is Development/Languages/Python? Shouldn’t they both be Productivity/File utilities, or perhaps
It's a good point. If rpm could do multiple categories like XDG .desktop files, packages could appear in multiple places in the YaST tree. Imagine that.. gedit.spec:Tags: editors gnome-desktop gtk leafpad.spec:Tags: editors xfce-desktop gtk nano.spec:Tags: editors
6.
Or perhaps _fixed_ groups should be abandoned altogether. http://freshcode.club works and not too bad. People make their own tags there. One just needs to clean up obvious duplicates ("editor" vs "editors" or something) every now and then. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 05/30/2018 05:40 PM, Jan Engelhardt wrote:
gedit.spec:Tags: editors gnome-desktop gtk leafpad.spec:Tags: editors xfce-desktop gtk nano.spec:Tags: editors
6.
Or perhaps _fixed_ groups should be abandoned altogether. http://freshcode.club works and not too bad. People make their own tags there. One just needs to clean up obvious duplicates ("editor" vs "editors" or something) every now and then.
You have a very good point. And is not so different from reality in other distros. For example, Debian has been using package tags[1] for a number of years in addition to groups. This makes it much easier to find things you want. Here's an example, https://debtags.debian.org/search/?wl=&q=editor&qf=default and then look at the right to refine these things. This then becomes a kind of self-organized free-form indexing which makes much more sense than static groups. On the other hand, static groups also exist. This allows people to see what packages they have installed in a given group. But it is probably less useful to search for new packages. - Adam [1] https://debtags.debian.org/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, 2018-05-29 at 12:45 +0200, Tomas Chvatal wrote:
Hi all,
We have pretty strict requirements how the group tags are shown. [0]
But there are only 2 ways to use it, 1) yast view based on groups 2) using rpm -q to get information for the individual package. For all other purposes from zypp/packagekit this stuff is ignored.
In general it does not really make sense to install packages based on groups. As Fedora already deprecated this tag it would make sense for us to drop it too [1][2].
Proposed change would be to kill the Yast UI and then have spec-cleaner to drop the part where needed. It won't break on older releases as it would simply have Undefined as a group.
Cheers
Tom
Just curious: did you run this through the SLE fate process already? There the group is even strictly enforced. Dropping this requirement on the openSUSE side will cause our downstream to suffer from it, unless they give up on the requirement too. Cheers Dominique
On Tue, May 29, 2018 at 7:20 AM Dominique Leuenberger / DimStar < dimstar@opensuse.org> wrote:
On Tue, 2018-05-29 at 12:45 +0200, Tomas Chvatal wrote:
Hi all,
We have pretty strict requirements how the group tags are shown. [0]
But there are only 2 ways to use it, 1) yast view based on groups 2) using rpm -q to get information for the individual package. For all other purposes from zypp/packagekit this stuff is ignored.
In general it does not really make sense to install packages based on groups. As Fedora already deprecated this tag it would make sense for us to drop it too [1][2].
Proposed change would be to kill the Yast UI and then have spec-cleaner to drop the part where needed. It won't break on older releases as it would simply have Undefined as a group.
Cheers
Tom
Just curious: did you run this through the SLE fate process already? There the group is even strictly enforced. Dropping this requirement on the openSUSE side will cause our downstream to suffer from it, unless they give up on the requirement too.
PackageKit groups are mapped to RPM groups in the Zypp backend, as opposed to patterns (or RH/Fedora comps groups, as they are for the Yum backend). This is used by Apper (a KDE frontend for PackageKit). -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 05/29/2018 01:22 PM, Neal Gompa wrote:
PackageKit groups are mapped to RPM groups in the Zypp backend, as opposed to patterns (or RH/Fedora comps groups, as they are for the Yum backend). This is used by Apper (a KDE frontend for PackageKit).
Actually I always thought we would limit the number of groups to those provided by PackageKit, that are much easier to choose from than the insanity we have with Groups. This would also limit all your other problems because we still had a Group :) Greetings, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On mardi 29 mai 2018 13:22:09 CEST Neal Gompa wrote:
PackageKit groups are mapped to RPM groups in the Zypp backend, as opposed to patterns (or RH/Fedora comps groups, as they are for the Yum backend). This is used by Apper (a KDE frontend for PackageKit).
Note that Apper is gone, it's not a blocker :) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Le mardi 29 mai 2018, 16:15:57 CEST Christophe Giboudeaux a écrit :
On mardi 29 mai 2018 13:22:09 CEST Neal Gompa wrote:
PackageKit groups are mapped to RPM groups in the Zypp backend, as opposed to patterns (or RH/Fedora comps groups, as they are for the Yum backend). This is used by Apper (a KDE frontend for PackageKit).
Note that Apper is gone, it's not a blocker :)*
Apper is gone, but doesn't Discover uses PackageKit to do the same? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Dominique Leuenberger / DimStar píše v Út 29. 05. 2018 v 13:18 +0200:
Just curious: did you run this through the SLE fate process already? There the group is even strictly enforced. Dropping this requirement on the openSUSE side will cause our downstream to suffer from it, unless they give up on the requirement too.
I so far only spoke with Yast-ers and they would be fine with it from Technical PoV. So if you know someone with a stake in this could you poke them to read this thread? From my side we could drop it even on SLE without pushback . Tom
On 05/29/2018 07:52 AM, Tomas Chvatal wrote:
Dominique Leuenberger / DimStar píše v Út 29. 05. 2018 v 13:18 +0200:
Just curious: did you run this through the SLE fate process already? There the group is even strictly enforced. Dropping this requirement on the openSUSE side will cause our downstream to suffer from it, unless they give up on the requirement too.
I so far only spoke with Yast-ers and they would be fine with it from Technical PoV.
So if you know someone with a stake in this could you poke them to read this thread? From my side we could drop it even on SLE without pushback .
Packages without a Group: definition build in IBS, but they generate a warning for SLE 15 builds, interestingly enough no warning for SLE 12 SP3 is generated. Thus this exercise would in effect train people to ignore warnings, something I am not very fond of. I'd say the issue of SLE builds in IBS not triggering warnings when no Group is specified should be addressed first. Also, keep in mind that not every package in SLE is a fork. There are many packages that are duplicates/copies. That implies that any changes in YaST would need to be carried back into SLE. Otherwise a lot of work is generated for other people as they have to start maintaining forks rather than duplicates/copies. Unless Group: becomes optional, i.e. spec-cleaner does NOT remove it, and teams maintaining packages that are duplicates/copies in both OBS and IBS can drop Group: when it works for them, which without changes in YaST could be 10 years from now. Later, Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU Distinguished Architect LINUX Team Lead Public Cloud rjschwei@suse.com IRC: robjo
Robert Schweikert píše v Út 29. 05. 2018 v 09:03 -0400:
On 05/29/2018 07:52 AM, Tomas Chvatal wrote:
Dominique Leuenberger / DimStar píše v Út 29. 05. 2018 v 13:18 +0200:
Just curious: did you run this through the SLE fate process already? There the group is even strictly enforced. Dropping this requirement on the openSUSE side will cause our downstream to suffer from it, unless they give up on the requirement too.
I so far only spoke with Yast-ers and they would be fine with it from Technical PoV.
So if you know someone with a stake in this could you poke them to read this thread? From my side we could drop it even on SLE without pushback .
Packages without a Group: definition build in IBS, but they generate a warning for SLE 15 builds, interestingly enough no warning for SLE 12 SP3 is generated. Thus this exercise would in effect train people to ignore warnings, something I am not very fond of.
I'd say the issue of SLE builds in IBS not triggering warnings when no Group is specified should be addressed first.
Also, keep in mind that not every package in SLE is a fork. There are many packages that are duplicates/copies. That implies that any changes in YaST would need to be carried back into SLE. Otherwise a lot of work is generated for other people as they have to start maintaining forks rather than duplicates/copies. Unless Group: becomes optional, i.e. spec-cleaner does NOT remove it, and teams maintaining packages that are duplicates/copies in both OBS and IBS can drop Group: when it works for them, which without changes in YaST could be 10 years from now.
No worries. The plan is to kill it retrospectively. It is useless even on SLE12/15. If it disappears nobody would really notice. RH and others already killed it for rhel6 so we should be fine in that respective PoV as well... Basically even on SLE15 when I see it we just generate rpmlint warning, which can be confusing, but we always say to people that only rpmlint they should watch is Tumbleweed and fix/report errors only on old codestreams thus that should be also okay. The warning: [ 9s] libusb-1_0-0.x86_64: W: non-standard-group Unspecified [ 9s] libusb-1_0.src: W: non-standard-group Unspecified ... The content of the rpm informations: Name : libusb-1_0-0 Version : 1.0.21 Release : 0 Architecture: x86_64 Install Date: (not installed) Group : Unspecified Size : 162392 License : LGPL-2.1-or-later Signature : (none) Source RPM : libusb-1_0-1.0.21-0.src.rpm Build Date : Út 29. květen 2018, 15:19:25 CEST Build Host : bugaboo Relocations : (not relocatable) Vendor : obs://build.opensuse.org/hardware URL : http://libusb.info/ Summary : USB Library Description : Libusb is a library that allows userspace access to USB devices. Distribution: hardware / openSUSE_Tumbleweed Cheers Tom
On Tuesday, 29 May 2018 15:20 Tomas Chvatal wrote:
No worries. The plan is to kill it retrospectively. It is useless even on SLE12/15. If it disappears nobody would really notice.
I would. SLE11 SP4 build fails without the Group tag. I know some people who only look forward consider it "ancient" but it's a product which is still under regular support and in wide use. Could we please stop introducing more and more unnecessary build breakages at least for the 10 months until it goes LTSS? While I agree that it's a nuisance to still have Group, BuildRoot or %defattr in specfiles, it's much worse to have to work around more and more build breakages added _only_ in the name of cleanup. Michal Kubecek "All his life he looked away to the future, the horizon. Never his mind on where he was. What he was doing." -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Moin, On May 29, 18 13:52:26 +0200, Tomas Chvatal wrote:
Dominique Leuenberger / DimStar píše v Út 29. 05. 2018 v 13:18 +0200:
Just curious: did you run this through the SLE fate process already? There the group is even strictly enforced. Dropping this requirement on the openSUSE side will cause our downstream to suffer from it, unless they give up on the requirement too.
I so far only spoke with Yast-ers and they would be fine with it from Technical PoV.
Which is just a small subset :)
So if you know someone with a stake in this could you poke them to read this thread? From my side we could drop it even on SLE without pushback
Well, it would require a lot of changes, including the building scripts and checks, but more importantly on the tools in the OS which have the groups shown. All not a big drama if prepared and planned, so technically or sure doable. But not all that is technically doable is good or usefull ;) I personally like the groups. They give you a good hint what a package is for. Of course, the _name_ of the package is more often than not useless in that regard. (As a longtime mutt user, I know what ths package does. But a newby? Not from the name.) And then there's the description. For main packages it's normally ok. But subpackages are a different beast. No release without me filling a few bugs regarding description or summary bugs. The groups? Well, they are more often ok than not. Of course, you have there the problem that you can sort some packages in more than one group. But in general the mass (at least those used on SLE, from my experience) are roughly ok - one can always debate the "subgroup", but the "groupfamily" fits normally). In my opinion the group can offer a valid starting point if you search something, but on the other hand I frealy admit that patterns are a better help for new users. I would like to keep them, and have them limited to a reasonable amount of gorups. In reality, the group fileld of a package should not change much. New subpackages or package splits may require one, but that should not be a big thing. If enough help is provided - and guidance which group to use. (There's still the rumour of different group lists that exist. It should be one. Not two.) Stefan
.
Tom
-- Stefan Behlert, SUSE LINUX Enterprise Server Maxfeldstr. 5, D-90409 Nuernberg, Germany Phone +49-911-74053-0 SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, 2018-05-29 at 12:45 +0200, Tomas Chvatal wrote:
Hi all,
We have pretty strict requirements how the group tags are shown. [0]
But there are only 2 ways to use it, 1) yast view based on groups 2) using rpm -q to get information for the individual package. For all other purposes from zypp/packagekit this stuff is ignored.
I'm using the rpm Group tag as a way to index software in Package Hub by pseudo category since there is nothing else I could find within the repo data to do the job. It's not perfect, but better than nothing: https://packagehub.suse.com/package-categories/archiving/
In general it does not really make sense to install packages based on groups. As Fedora already deprecated this tag it would make sense for us to drop it too [1][2].
Proposed change would be to kill the Yast UI and then have spec-cleaner to drop the part where needed. It won't break on older releases as it would simply have Undefined as a group.
What would be the alternative for grouping and indexing the software in the distro by some form of categories? I had once thought about suggesting that we start using .desktop files with proper categories for every RPM, but I'm not sure if that makes sense for anything outside of desktop applications. Is there a different standard we can leverage? The other option would be to maintain a database of tags/categories outside of the rpms for "app-store" type interfaces like software.o.o or the Package Hub website. But a centralized database would really be nice vs everyone baking their own. I'm not opposed to killing the tag, but would like to see a better option. -Scott
Cheers
Tom
[0] https://en.opensuse.org/openSUSE:Package_group_guidelines [1] https://fedoraproject.org/wiki/Packaging:Guidelines#Tags_and_Sectio ns [2] https://fedoraproject.org/wiki/RPMGroups
participants (14)
-
Adam Majer -
Christophe Giboudeaux -
Dominique Leuenberger / DimStar -
Jan Engelhardt -
Matěj Cepl -
Michal Kubecek -
Neal Gompa -
Pierre de Villemereuil -
Robert Schweikert -
Scott Bahling -
Stefan Behlert -
Stephan Kulow -
Tomas Chvatal -
Wolfgang Rosenauer