On Thu, 2014-11-06 at 07:10 +0800, Ed Greshko wrote: > On 11/06/14 07:06, Adrian wrote: > > > > What is the advantage of using dnf instead of yum ? > > > > > > None.... > > yum group install gnome-desktop > > Would have worked just as well.... > > The *problem* however is finding this out when a list of the groups doesn't show it in either yum or dnf. It's not a user-visible group. The comps groups are kind of a bit of a mess now; no-one has overall responsibility for them and they've just been sort of poked ad hoc to get the 'Product'ization stuff looking right, one issue at a time. It's easy enough to go straight to the source to see what's actually going on - just clone comps git: git clone https://git.fedorahosted.org/git/comps.git and look at 'comps-f21.xml.in'. The groups are listed there, in a fairly clear format. <group> entries are the things yum calls "groups". <environment> entries are the things yum calls "environment groups". Groups can be marked 'uservisible' or not. Groups that are marked 'uservisible' appear in yum / dnf 'grouplist'. Environment groups appear on the left hand side of anaconda's package selection screen, and in yum / dnf 'grouplist'. Environment groups must have a <grouplist> section. These are the package groups that will always be installed as a part of that environment group. Environment groups can have a <optionlist> section. This contains regular 'groups'. groups listed as part of an environment group's 'option list' are the ones that appear at the top of the list on the right hand side of anaconda's package selection screen *only when that environment group is selected*. Groups that are marked 'uservisible' but are not part of the currently-selected environment group's "optionlist" appear in the bottom section of that list (there's a small grey separator line), regardless of what environment is selected. Groups cannot contain other groups - so there's really just one level of nesting available, groups within environment groups. The comps system is really a bit too inflexible for our needs in a Product-ized world, because it's hard to make it properly cover both the case of install-time deployment and the case of post-install deployment. At install time, if you're deploying 'Workstation', we really need you to get the fedora-release-workstation package installed, so the 'workstation-product-environment' environment group contains the 'workstation-product' group, which includes the 'fedora-release-workstation' package. But that means you can't easily add it on to a KDE install, because the KDE install already has the fedora-release-nonproduct group. It's not trivial to work around this because it'd really require another layer of nesting or some other form of extra flexibility to cover all cases. As things stand, the 'gnome-desktop' group still exists but is not marked uservisible, so you can use that, but I'm not sure if its continued existence is something anyone's consciously planned or just a happenstance. The whole 'environment group' system was designed to back the newUI package selection UI design (AIUI), it wasn't really designed to back the whole Product system at all, and it seems no-one quite came up with a fully co-ordinated plan for how we'd do the comps groups and kickstarts for Products, it just sort of has been hacked together as we've gone along. Which is probably why it's all a little incoherent now. I think if we were just whiteboarding it from scratch we'd want to set things up so that the groups you could pick at the left-hand side of anaconda's UI would pull in the appropriate 'fedora-release-foo' package, while 'yum grouplist' would show you groups which would deploy the same set of actual packages for the desktop environment in question but would not pull in any particular 'fedora-release' package. I don't believe that's fully possible right now because you can't make environment groups visible in anaconda but not visible in yum. Environment groups don't have any kind of 'visibility' property - if they exist, they show up, both in anaconda and in yum. comps also has weird things called <category>s down the bottom, which aren't used by anaconda or yum but are used by (IIRC) yumex. Bill, Stephen, Matt, Kalev - I think we could stand to take another look at this. I see two immediate issues: 1) Workstation is set up rather differently to the other desktop-y products/environments. There's rather an overlap between the 'workstation-product' group and the 'gnome-desktop' group. I'd sort of expect the 'workstation-product-environment' env group would include the 'gnome-desktop' group and then another group which pulled in the things that we want to add that make up the 'workstation product', perhaps? This is how the other desktop small-p products/environments work - kde-desktop-environment pulls in @kde-desktop (plus other package groups) and @fedora-release-nonproduct , xfce-desktop-environment pulls in @xfce-desktop and @fedora-release-nonproduct, etc. 2) We just don't have a good story for installing extra desktops post-install any more. The only 'desktop' groups visible in 'yum grouplist' are the environment groups, but you can't use those because of fedora-release package conflicts. You can install the 'XXX-desktop' package groups directly, but these aren't visible in yum's list at all (I think we stopped making them user-visible when we set up the whole 'environment group' thing on the basis people should just install the env groups). So you can't install the groups you can see, but you can install the groups you can't see... -- 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
