On Sat, 2013-12-14 at 16:29 -0800, Adam Williamson wrote: > OK, I think I got as far as I can with this. I was wrong about some > things, above - I was reading /var/lib/yum/groups/installed wrong. It's > actually rather simpler than I thought. It was so simple I spent the rest of the day looking into the *other* bugs in this area :) I think I've finally investigated as much as I can. In the end, I think there are possibly four different bugs, many of them inter-related or similar: https://bugzilla.redhat.com/show_bug.cgi?id=1014202 https://bugzilla.redhat.com/show_bug.cgi?id=1043207 https://bugzilla.redhat.com/show_bug.cgi?id=1043221 https://bugzilla.redhat.com/show_bug.cgi?id=1043231 All of the following is, of course, my fallible QA-monkey deduction, so I might be wrong. But I think I'm right. :) When you ask them to install an environment group, both different functions that do 'install a group' call out to another function, and if it returns a GroupError, assume that meant the group they were called against doesn't exist. This is an unsafe assumption: for each of these, there are actually cases where getting a GroupError back means something different. This is #1014202. Due to another bug - #1043231 - you actually run into this issue any time you run 'yum groupinstall (installed_environment_group)'. There's a similar but different bug in one of the two functions when you call it to install a package group: if you call it against an installed package group, it erroneously prints 'group (groupname) does not exist'. The *other* of the two functions doesn't have this problem. You can demonstrate this one trivially: compare the output of 'yum install @installed_group' and 'yum group install installed_group'. The first one prints the warning, the second doesn't. I wasn't able to figure out *why* the check goes wrong, but that's what's going on. This is #1043207. The reason you often see one or more of these warnings on 'yum update' is that yum calls one of the 'install a group' functions when you run 'yum update' and prints the warnings in that case, even though I think the devs were only thinking about the case where you directly run "yum install @nonexistentgroup" when they added the warnings. I've suggested that the warnings shouldn't be printed when the 'install a group' function is being called indirectly like that: that's #1043221 . yum calls _at_groupinstall, the function that suffers from #1043207 - so if yum believes you have any groups installed, every time you run 'yum update', you get a 'group (groupname) is not installed' warning for every group that is installed. The most complex bug is #1043231. yum tries to keep track of what package groups were installed as a result of the installation of what environment groups, but this seems to be completely broken: it winds up believing that no package group was ever installed due to the installation of an environment group. (If anyone has a /var/lib/yum/groups/environment with the word 'true' in it anywhere, let me know; it means I might be wrong about this). This is bad in itself, and it's also the ultimate reason why 'yum groupinstall (installed_environment_group)' claims the group doesn't exist: through a dull chain of events described in https://bugzilla.redhat.com/show_bug.cgi?id=1014202#c22 , the fact that no package group is considered to have been installed as a part of that environment group causes a GroupError to be raised, and as we learned earlier (if we were paying attention!), bug #1014202 means that when this happens, yum claims the group doesn't exist. It's that simple! I'm sure James will have it all cleaned up in ten minutes on Monday morning ;) Note that all of the above is relevant only when the F19 "Yum groups as objects" feature is active: https://fedoraproject.org/wiki/Features/YumGroupsAsObjects . This is the feature that causes /var/lib/yum/groups/installed and /var/lib/yum/groups/environment to exist at all - it's the feature whereby yum tries to keep track over time of what package and environment groups are installed, instead of only working with them on the fly when you actually run a 'group' command. One of the workarounds that people have been passing around is setting yum's 'group_command' option to 'compat', which you can do directly in /etc/yum.conf or by running 'yum-config-manager --save --setopt=group_command=compat'. All this does is make yum revert to its older behaviour and completely turn off all the 'groups as objects' stuff, which means you'll avoid all of these bugs. The 'groups as objects' stuff is better in theory than the old behaviour, but given how broken it seems to be at present, setting it to 'compat' probably isn't a bad idea. Oh, and based on reports I've read, I'd strongly recommend against running 'yum group mark convert', as yum apparently suggests to you at times. What this is supposed to do, roughly, is "convert" a legacy system to 'groups as objects' - it tries to figure out from your installed package set and (I don't know what else, unicorn droppings?) which groups you 'have installed', and write that info out to /var/lib/yum/groups/* . However, it seems like in practice, it decides that any group from which you have even a single mandatory or default package is 'installed', and consequently, your next 'yum update' will try to pull in all the other packages from all those groups, which you probably don't want. I need to verify those reports and check if a bug's been filed, though, that's next on my list. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
