Bug 1160917
Summary: | fedora-release-(product) conflicts when installing environment groups which specify a different product to the currently-installed one | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Adam Williamson <awilliam> |
Component: | distribution | Assignee: | Václav Pavlín <vpavlin> |
Status: | CLOSED EOL | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | high | Docs Contact: | |
Priority: | unspecified | ||
Version: | 21 | CC: | bugzilla, dennis, djuran, edgar.hoch, ed.greshko, garrett.mitchener, gczarcinski, gholms, jindrich.novy, johannes.lips, jon.dufresne, jonsteyn, jreznik, jsastreh, ltoscano, mcatanzaro+wrong-account-do-not-cc, mfabian, michael.bessolov, mihai, myroslav, philip, poelstra, rcyriac, rdieter, robatino, samuel-rhbugs, sanjay.ankur, scott |
Target Milestone: | --- | Keywords: | CommonBugs |
Target Release: | --- | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: | https://fedoraproject.org/wiki/Common_F21_bugs#environment-product-conflicts | ||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2015-12-02 04:44:32 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: | |||
Bug Depends On: | |||
Bug Blocks: | 1146487 |
Description
Adam Williamson
2014-11-06 00:47:40 UTC
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. |