Bug 1043202

Summary:	Recently-introduced check for 'existent' groups being run too often
Product:	[Fedora] Fedora	Reporter:	Adam Williamson <awilliam>
Component:	yum	Assignee:	Packaging Maintenance Team <packaging-team-maint>
Status:	CLOSED NOTABUG	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	low	Docs Contact:
Priority:	unspecified
Version:	20	CC:	admiller, bitlord0xff, ffesti, firas.alkafri, packaging-team-maint, pnemade, zpavlas
Target Milestone:	---
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2013-12-15 00:31:37 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Adam Williamson 2013-12-14 22:16:08 UTC

I wasn't quite sure which bit of this behaviour to identify as the bug, but I took a shot.

Recently, a check was added to yum:

http://yum.baseurl.org/gitweb?p=yum.git;a=commit;h=ff5416b1532fe43c68bf51ae30751504885a501a

"Give same non-exist msg. for install @foo as group install foo. BZ 1018833."

From the bug report and the log message, it reads like it was expected that this check would only be hit and the error message only displayed if the user ran something like:

"yum install @non-existent-group"

However, the check actually appears to be hit on other operations. It at least appears to happen on any 'yum upgrade' operation. I see it on my system:

[root@adam yum]# yum upgrade
Loaded plugins: auto-update-debuginfo, langpacks, refresh-packagekit
side | 2.9 kB 00:00
Warning: group cinnamon-desktop does not exist.
No packages marked for update
[root@adam yum]#

I know it's hitting this particular check, because if I comment this specific check out of __init__.py (and none of the dozen or so similar checks in that file and cli.py...), then I no longer see it.

Quite a lot of people have reported seeing these 'group foo does not exist' errors - for some people, quite a lot of them - since yum -120 went stable, and I'm pretty sure this is the culprit in a lot of the cases. But I think there are other bugs going on in the area of groups and group checks and groups-as-objects too, and I haven't really nailed 'em all down yet.

The group that is identified as 'non-existent' for me, cinnamon-desktop, is listed in /var/lib/yum/groups/installed . Anyone who's had a Fedora system installed for a while will likely have groups listed in that file which no longer exist, as group names change in comps relatively often.

There's another element in play here, too. My /var/lib/yum/groups/installed contains several other non-existent cinnamon 'groups':

[adamw@adam comps (master %)]$ grep cinn /var/lib/yum/groups/installed
cinnamon-desktop
cinnamon
cinnamon-control-center
cinnamon-screensaver

but I only get the error for 'cinnamon-desktop'. I think the difference is the 'cinnamon-desktop' group actually *does* exist, but is hidden. The other groups don't exist at all.

So my best guess at characterising this issue is...

Somehow, this check is run and fails for groups that:

* are listed in /var/lib/yum/groups/installed
* exist as normal (not environment) groups in comps, but have 'uservisible' set false

when you run 'yum update'.

Comment 1 Adam Williamson 2013-12-14 22:21:03 UTC

*** Bug 1039348 has been marked as a duplicate of this bug. ***

Comment 2 Adam Williamson 2013-12-14 22:21:41 UTC

This bug affects both F19 and F20, as they both got the updated yum.

Comment 3 Adam Williamson 2013-12-14 23:12:00 UTC

So some of my diagnosis is wrong - I was reading /var/lib/yum/groups/installed wrong. It's not a list of groups, one per line, it lists a group, then a count of packages installed that are associated with it, then the package names (more or less).

I'm trying to figure out why the check actually fails for cinnamon-desktop on my system, and it seems rather odd. But I'll file a new bug for that to avoid confusing this one. It is definitely the case that the check is being hit on 'yum upgrade', when I don't think it was intended to.

Comment 4 Adam Williamson 2013-12-14 23:36:51 UTC

I've filed #1043207 for the part of the bug you can describe as 'this check fails for a group that really does exist'.

Comment 5 Adam Williamson 2013-12-15 00:13:56 UTC

As to why this code path is being hit when you do 'yum update'...well, the check is in the function _at_groupinstall in __init__.py . There is a large chunk of code at the top of the function install in the same file which I don't grok at all, but the comment above it is rather interesting:

        #  This is kind of hacky, we really need a better way to do errors than
        # doing them directly from .install/etc. ... but this is easy. *sigh*.
        #  We are only using this in "groupinstall" atm. ... so we don't have
        # a long list of "blah already installed." messages when people run
        # "groupinstall mygroup" in yum-cron etc.

and that function is the only other place in all of yum where I see _at_groupinstall:

            if 'pattern' in kwargs:
                if kwargs['pattern'] and kwargs['pattern'][0] == '-':
                    return self._minus_deselect(kwargs['pattern'])

                if kwargs['pattern'] and kwargs['pattern'][0] == '@':
                    return self._at_groupinstall(kwargs['pattern'])

I'm really not sure how the hell all of this works, but...that seems like it's possibly relevant. It may be that this part - this codepath being hit on running 'yum update' - is not actually a bug, and the only bug is #1043207 , which I'm pretty sure now is as simple as "yum install @installed-group claims installed-group does not exist".

Comment 6 Adam Williamson 2013-12-15 00:31:37 UTC

I think the real bug here is https://bugzilla.redhat.com/show_bug.cgi?id=1043207 , "the check in _at_groupinstall is broken for installed groups", not this bug, "_at_groupinstall is being run on yum update". It kinda makes sense to call one of the 'group install' functions on "yum update", I presume that's how yum looks for new packages in installed groups and adds them. So I think I'll close this one.