The Product-ization stuff has left us with a bit of a pickle regarding post-install addition of desktop groups - adding any other environment group to a Product install, or adding a Product environment group to any non-Product install. If you install Fedora 21 and run 'yum grouplist', you will see the environment groups for all the various desktops we include - that is, you'll see "Fedora Workstation" (which is actually the environment group 'workstation-product-environment'), "KDE Plasma Workspaces" (which is actually the environment group 'kde-desktop-environment'), "Xfce Desktop" (which is actually the environment group 'xfce-desktop-environment'), and so on. You will *not* see the *package* groups for each desktop - 'gnome-desktop', 'kde-desktop', 'xfce-desktop' and so on. None of those is marked <uservisible>true</uservisible> in comps, so they do not appear in the list unless you pass an extra parameter. Unfortunately, you can't actually install any of the other desktop environment groups if you installed Workstation. All the other desktop environment groups include the package group fedora-release-nonproduct , which simply pulls in the fedora-release-nonproduct package. So if you install Workstation then try 'yum groupinstall KDE Plasma Workspaces' or 'yum install @^kde-desktop-environment' (which do the same thing), it fails, because that wants to install fedora-release-nonproduct, which conflicts with fedora-release-workstation from your Workstation installation: Error: fedora-release-workstation conflicts with fedora-release-nonproduct-21-0.16.noarch Error: fedora-release-nonproduct conflicts with fedora-release-workstation-21-0.16.noarch Similarly, if you install say the KDE live image, then try and install the "Fedora Workstation" group with yum, it'll fail because it wants to install fedora-release-workstation, which conflicts with the installed fedora-release-nonproduct. You can add any non-Product environment group to any non-Product install, of course (so you can install from the KDE live and then add Xfce, for instance). It *is* possible to install another desktop - but only by installing the foo-desktop package group, which is not visible in yum's list, so there's no reason you'd know to do it unless you read up on this bug somehow. So you can install Workstation and then do: yum groupinstall kde-desktop and it'll work fine (though you won't get all the other groups you'd get from kde-desktop-environment). But there's no easy way to know you can do that, because the group is not user visible. I don't know if there's a very easy way out of this, because the comps/yum/anaconda combination doesn't currently have the flexibility. We can't make certain environment groups visible in anaconda and others visible in yum (for instance) - the system doesn't have that capability. We can't have the environment groups behave differently depending whether we're in anaconda or post-install. One thing we could consider as a quick hack for F21 is to stop yum (and dnf) showing the environment groups, and make the desktop package groups user-visible. It's not perfect, because as noted above you *can* mix-and-match the non-Product environment groups, but it might be something we'd see as overall an improvement. For a 'proper' solution, I'm thinking perhaps we need to extend comps a bit (more). Perhaps environment groups need a <release> or <product> property, which defines the fedora-release-(product) package/group that's associated with that environment; anaconda and yum would then install the <product> package/group for an environment *only if no other product package/group was already installed/selected for installation*, or something like that.
Guys, I think everything works fine asis!! After doing a workstation live install and doing yum update to get current, you can install the complete kde-desktop-environment with: yum group install kde-desktop-environment --exclude=fedora-release\*
Actually, Gene, that is a workaround, not a fix :)
yeah. it's a neat one we can document (I didn't know yum would let you do that), but still a workaround... I haven't looked yet at whether yum will fail or exclude the package and succeed if a packagereq with dep issues is explicitly marked 'default' in comps (as opposed to having no type). I did check if maybe anaconda installs 'optional' packagereqs by default, which would give us a way out of this problem, but sadly it doesn't.
Additionally you can't switch or install the different products at the moment rpm -qa fedora-release\* fedora-release-21-1.noarch fedora-release-notes-21.06-1.fc21.noarch root@newcaprica:[johannes]# yum install fedora-release-nonproduct Loaded plugins: fastestmirror, langpacks, rpm-warm-cache, tmprepo Loading mirror speeds from cached hostfile * fedora: mirror2.hs-esslingen.de * rpmfusion-free-rawhide: mirror.karneval.cz * rpmfusion-nonfree-rawhide: mirror.karneval.cz * updates: mirror.euserv.net Resolving Dependencies --> Running transaction check ---> Package fedora-release-nonproduct.noarch 0:21-0.16 will be installed --> Processing Dependency: fedora-release = 21-0.16 for package: fedora-release-nonproduct-21-0.16.noarch --> Finished Dependency Resolution --> Finding unneeded leftover dependencies Found and removing 0 unneeded dependencies Error: Package: fedora-release-nonproduct-21-0.16.noarch (fedora) Requires: fedora-release = 21-0.16 Installed: fedora-release-21-1.noarch (@updates-testing) fedora-release = 21-1 Available: fedora-release-21-0.16.noarch (fedora) fedora-release = 21-0.16 You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest I upgraded using yum, but the install and swap of the products should work nonetheless, or?
that just looks like you have a repo issue; you need to be getting it from updates-testing.
Ok, sorry for the noise works with the updates-testing version.
How is one supposed to install GNOME gui on a "Server Product" exactly? Am I missing something? The only group that seems like a gui is "Fedora Workstation" which conflicts with "Fedora Server". One used to have a group called "GNOME Desktop" or something, but it's gone and the only replacement conflicts at the base os level. Attempting the workaround in comment#1 results in conflicts with firewalld-server vs firewalld-workstation. Ex tending the workaround for these two packages as well seems to be doing something though. Surely there is a way to add GNOME to a "Server" build.
Try --skip-broken: http://fedoraserver-wgblog.rhcloud.com/graphical-desktop-environments-on-fedora-21-server/ the @gnome-desktop group does still exist, also, it's just hidden.
It doesn't look like the hack works. sudo yum group install "Fedora Workstation" --exclude=fedora-release\* .... Error: firewalld-config-standard conflicts with generic-release-workstation-21-7.noarch Error: firewalld-config-workstation conflicts with firewalld-config-standard-0.3.12-1.fc21.noarch Error: generic-release conflicts with fedora-release-21-2.noarch Error: firewalld-config-standard conflicts with firewalld-config-workstation-0.3.12-1.fc21.noarch You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest See the fpaste http://fpaste.org/159053/ on contrary "sudo yum group install gnome-desktop" doesn't produce any conflicts but there is no evident way to know the exact group name of each of the desktop environments.
Okay "groupinstall" works but "group install" doesn't. I thought they were the same thing.
oh, sigh, yum's crazy code bites again. nope, they're not the same, yum hits three different codepaths for 'group install' foo, 'groupinstall foo', and 'install @foo'. I'll add an explicit note to the commonbugs to say use 'groupinstall'. thanks for the info.
I want to use fedup to upgrade my system from Fedora 20 to Fedora 21. I think I'm on topic here. I see this error message after giving the command sudo fedup --network 21 --product=workstation package conflicts fedora-release-workstation conflicts with fedora-release-nonproduct-21-2.noarch fedora-release-nonproduct conflicts with fedora-release-workstation-21-2.noarch Continue with the upgrade at your own risk. QUESTION: If I continue will I mess up my system? I can't tell from the previous comments.
That's a somewhat different case, first time I've seen it happen with fedup. Do you somehow have fedora-release-nonproduct installed already? Oh, or perhaps it knows you have an environment group installed which has added the 'nonproduct' package in F21 comps, like KDE or Xfce or something; I can see that would be possible. I can't honestly guess what will happen on the upgrade, but I doubt it could possibly break the system, as the -release-product packages aren't reaaaaaaaallly needed, they don't contain anything vital. So my guess would be that you'd be fine, but I'm not going to put any money on it. :)
(In reply to Adam Williamson (Red Hat) from comment #13) > That's a somewhat different case, first time I've seen it happen with fedup. > Do you somehow have fedora-release-nonproduct installed already? Oh, or > perhaps it knows you have an environment group installed which has added the > 'nonproduct' package in F21 comps, like KDE or Xfce or something; I can see > that would be possible. > I'll file a new bug against fedup. I haven't done anything fancy or installed any weird packages that I know of. I did do a groupinstall of "MATE Desktop." $ rpm -qa | grep fedora-release fedora-release-20-3.noarch fedora-release-notes-20-0.9.noarch
"I did do a groupinstall of "MATE Desktop."" That's very likely the trigger, yeah. In fact I think I can see what happened exactly, you hit a fun little confluence of behaviours. Whether you did 'yum groupinstall "MATE Desktop"' or 'yum groupinstall mate-desktop' you may well have hit https://bugzilla.redhat.com/show_bug.cgi?id=1151222 , and wound up installing the environment group mate-desktop-environment . In F21, mate-desktop-environment pulls in fedora-release-nonproduct . When fedup/yum (I'm not sure which is responsible in fact) knows you have a group installed, it will attempt to pull in packages newly included in that group when you upgrade - so your upgrade package set has fedora-release-nonproduct added, which conflicts with the fedora-release-workstation you get from your '--product workstation' . Software, isn't it fun. I can see a few things you can do if you don't want to risk the conflict. You can mark the MATE group as not being installed, yum has options to let you do that (then you could mark it as installed again post-fedup). Or you could use --product nonproduct and then try and pull in new packages from the Workstation group post-install, if you liked.
Fedora Workstation failed for me on KDE Spin sudo yum groupinstall "Fedora Workstation" --exclude fedora-release\* Error: firewalld-config-standard conflicts with generic-release-workstation-21-7.noarch Error: firewalld-config-workstation conflicts with firewalld-config-standard-0.3.12-1.fc21.noarch Error: generic-release conflicts with fedora-release-21-2.noarch Error: firewalld-config-standard conflicts with firewalld-config-workstation-0.3.12-1.fc21.noarch http://fpaste.org/160079/ Whereas gnome-desktop seems to resolve dep just fine. sudo yum groupinstall gnome-desktop --exclude fedora-release\*
gnome-desktop doesn't include any -release package, so you wouldn't even need the --exclude, there. We seem to keep getting different results from different testers for the other case, though...I'll tell mattdm to look at it again.
(In reply to John Poelstra from comment #12) > I want to use fedup to upgrade my system from Fedora 20 to Fedora 21. I > think I'm on topic here. > > I see this error message after giving the command > sudo fedup --network 21 --product=workstation > > package conflicts > fedora-release-workstation conflicts with > fedora-release-nonproduct-21-2.noarch > fedora-release-nonproduct conflicts with > fedora-release-workstation-21-2.noarch > Continue with the upgrade at your own risk. > > QUESTION: If I continue will I mess up my system? I can't tell from the > previous comments. I got this too. I ignored it and my system is still fine. Not sure whether I'm on a product or not though now. Question: What is the intended point of 'fedora-release-nonproduct'. Does it actually do anything useful?
(In reply to John Poelstra from comment #14) > (In reply to Adam Williamson (Red Hat) from comment #13) > > That's a somewhat different case, first time I've seen it happen with fedup. > > Do you somehow have fedora-release-nonproduct installed already? Oh, or > > perhaps it knows you have an environment group installed which has added the > > 'nonproduct' package in F21 comps, like KDE or Xfce or something; I can see > > that would be possible. > > > > I'll file a new bug against fedup. I haven't done anything fancy or > installed any weird packages that I know of. I did do a groupinstall of > "MATE Desktop." > > $ rpm -qa | grep fedora-release > fedora-release-20-3.noarch > fedora-release-notes-20-0.9.noarch Here's the separate bug I filed against fedup: https://bugzilla.redhat.com/show_bug.cgi?id=1174524
"Question: What is the intended point of 'fedora-release-nonproduct'. Does it actually do anything useful?" Not especially. For most of the F21 cycle the -release packages (fedora-release and generic-release) required "system-release-product", a virtual provide which all the (fedora/generic)-release-(product) packages provided; fedora-release-nonproduct is thus required for non-Product installs mainly to satisfy that dep. The dep was removed late in development, though. I don't fully know the rationale for either having it in the first place or for taking it out later, as I'm way behind on devel@ discussions. It was probably something to do with trying to ensure it's always possible to definitely identify a system's Product status, I guess? mattdm or sgallagh could probably explain.
So, is the intent here that MATE cannot co-exist with Workstation? Is this basically MATE's way of trying to declare itself a separate "product" from Workstation? (This is exactly why I wanted to have a policy for how that should be done, rather than just hardcoding four "approved" products in fedup...)
It's not MATE's 'fault'. All the environment groups include (whether directly or via one of the groups they contain) one of the fedora-product-(foo) packages. The Product environment groups include fedora-product-(environment). The non-Product ones include fedora-product-nonproduct . This was part of the whole Product design and was mandated as part of it. So not just MATE, but KDE, Xfce, LXDE, Cinnamon, Sugar and any other non-Product env groups we have pull in fedora-product-nonproduct . As I said in #c20, for most of the F21 cycle there was a requirement for a system-release-product package, so env groups had to specify *something* or they'd wind up getting the dep solved randomly by yum (which in practice meant they got fedora-release-cloud). The dep was dropped late in the dev cycle (actually it looks like it wasn't dropped from generic-release yet...), but the non-Product env groups weren't adjusted to not include fedora-product-nonproduct . I suppose we could try changing that, but it hasn't been tested. fedora-product-nonproduct doesn't pull anything in via Requires: nor include any files besides a license, so in theory just dropping it from the comps groups would probably not cause too many problems and would resolve quite a lot of these dep issues. But I don't think we can do it for a stable release, because it's baked into the frozen tree's comps. I don't know if the Product cabal has come up with any overall plans for tweaking the Product implementation for F22 yet, we'd have to ask sgallagh/mattdm.
Correction to #c22: "The Product environment groups include fedora-product-(environment)" should read "The Product environment groups include fedora-product-(product)".
I think the product design is wrong. A host can be a server and a workstation at the same time - it is often the case, especially for pcs. The products should be able to coexist on the same systems, e.g. to have desktops gnome, kde, lxde, xfce, etc., AND server services like dhcp, bind, apache, databases, etc. on the same system. Package groups (and environment groups) are a fine idea to quick install software which belongs together, but they should be mergeable, not be exclusive. If there would be no patch for fedora 21, would it be fixed in fedora 22?
An example: I have installed a pc using kickstart, using Fedora-Server-DVD-x86_64-21.iso (this is the only image for kickstart, if I had understood correctly). I don't (yet) know why, but it has installed package "fedora-release-server". If I try to remove thís package (yum remove fedora-release-server), then these packages will be removed as dependency. But I don't see a reason why anaconda, firewalld, fail2ban, revisor, etc. cannot be stay installed without fedora-release-server. anaconda anaconda-core anaconda-gui anaconda-tui fail2ban fail2ban-firewalld firewall-applet firewall-config firewalld firewalld-config-server initial-setup initial-setup-gui revisor revisor-cli revisor-comps revisor-gui revisor-unity rolekit I think the only true dependency is firewalld-config-server, because it contains product-specific configuration files, all other are not product specific.
This was discussed at length and rejected, and bugzilla is not the place to revisit that. You can certainly use components from all the flavors together in one Fedora installation; 'nonproduct' would be the recommended flavor to identify such an installation as.
What's going on in your example is that firewalld requires a firewall config package and you're removing the only one that's installed, so firewalld has to go too, so all its dependencies go. This is a limitation of the current way the flavor stuff is implemented that's quite difficult to avoid. It's not really intended (probably, ideally, you should get the non-flavor 'generic' config package in such a case), but it's also difficult to fix until we get some RPM enhancements that are slated for F23, AIUI.
So is there a way to put firewalld and a desktop on the same computer, or not? If so, could someone explain how? Because I really need to have both.
well, sure, but there are various different angles on this, we can't really help you without more details on what your situation is right now and what you want to achieve.
This message is a reminder that Fedora 21 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 21. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '21'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 21 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 21 changed to end-of-life (EOL) status on 2015-12-01. Fedora 21 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.