I installed Fedora-Live-Workstation-x86_64-21_Alpha-1.iso using qemu. qemu command line: ionice -c 3 qemu-kvm -enable-kvm -global qxl.ram_size=1x1024 -m 2048M -smp 2 -drive file=./Fedora-Live-Workstation-x86_64-21_Alpha-1.iso.qcow2,index=0,media=disk,cache=unsafe -localtime -serial file:/tmp/qemu-Fedora-Live-Workstation-x86_64-21_Alpha-1.iso.qcow2-output.log -name Fedora-Live-Workstation-x86_64-21_Alpha-1.iso.qcow2 -cdrom /local/mfabian/iso/f21-Alpha/Fedora-Live-Workstation-x86_64-21_Alpha-1.iso -boot c -spice port=6000,disable-ticketing,streaming-video=off -vga qxl -display vnc=:4 -net nic -net user,hostname=Fedora-Live-Workstation-x86_64-21_Alpha-1.iso.qcow2,hostfwd=tcp::5555-:22 -monitor stdio -usb As expected, I got a Gnome desktop. Now I wanted to install some other desktops for testing and did: “sudo yum groupinstall xfce-desktop-environment” ... It failed with: ... --> Processing Conflict: fedora-release-workstation-21-0.13.noarch conflicts fedora-release-standard --> Processing Conflict: fedora-release-standard-21-0.13.noarch conflicts fedora-release-workstation --> Finished Dependency Resolution Error: fedora-release-workstation conflicts with fedora-release-standard-21-0.13.noarch Error: fedora-release-standard conflicts with fedora-release-workstation-21-0.13.noarch You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest Same problem if I try to install any of the other desktop environments. KDE Plasma Workspaces (kde-desktop-environment) Xfce Desktop (xfce-desktop-environment) LXDE Desktop (lxde-desktop-environment) Cinnamon Desktop (cinnamon-desktop-environment) MATE Desktop (mate-desktop-environment) Sugar Desktop Environment (sugar-desktop-environment)
Yes, it looks like there's a bug in comps. 'fedora-release-standard' is explicitly added as a requirement instead of as a conditional requirement. <group> <id>fedora-release-standard</id> <_name>Generic Fedora release</_name> <_description/> <default>false</default> <uservisible>false</uservisible> <packagelist> <packagereq>fedora-release-standard</packagereq> </packagelist> </group> This is problematic, as @fedora-release-standard is included by the core and spin environments. I think we need to change this to 'default' instead of 'required' here.
On Fedora-Workstation-netinst-x86_64-21_Beta_TC1.iso, I could install xfce with “sudo yum groupinstall xfce-desktop-environment” without problems. So this seems fixed in F21 Beta TC1.
"'fedora-release-standard' is explicitly added as a requirement instead of as a conditional requirement" um, how do you mean? The syntax for specifying the type of the requirement is: <packagereq type="type">packagename</packagereq> there is no 'type=' parameter in the <packagereq>fedora-release-standard</packagereq> , so it's using whatever the default type is, not explicitly specifying a requirement type. This is a more general problem than just Xfce. You can barely install any environment group to 'extend' a Product installation, because most of them now pull in the fedora-release-standard group, and you hit this conflict. It happens, for instance, if you try to install any of the server environment groups to 'extend' your Fedora Server installation. At install time the way this works is you're offered the package groups in your selected environment's <optionlist> list, which works fine because the groups listed there are package groups, not environment groups - for a Server install, you can add the 'web-server' package group, for instance. But post-install, what yum shows you when you do 'yum group list' is the groups marked as <uservisible> in comps, and those are the environment groups. the 'web-server' package group is not uservisible, but the 'web-server-environment' environment group is. This means when you do 'yum group list' you see: [adamw@adam comps (master *%)]$ yum group list | grep -i web Web Server it seems like a pretty expected workflow for someone to run a Fedora Server install, then do 'yum group list' and say 'hey, I want a web server' and run 'yum group install "Web Server"' - which will fail, because it tries to pull in the web-server-environment group. Ditto installing Workstation and then wanting to add an alternative desktop. We probably need to re-think the groups yum offers for a Product-ized world, in general...but for now, somehow making it so environment groups can install on top of Products without a conflict might be good enough.
I have the same problem on a Fedora-Live-Workstation-x86_64-2 install. When I try to install "KDE Plasma Workspaces" I get this: ---> Package gnome-shell.x86_64 0:3.14.1-1.fc21 will be an update --> Processing Conflict: fedora-release-workstation-21-0.14.noarch conflicts fedora-release-standard --> Processing Conflict: fedora-release-workstation-21-0.14.noarch conflicts fedora-release-standard --> Processing Conflict: fedora-release-standard-21-0.14.noarch conflicts fedora-release-workstation --> Processing Conflict: fedora-release-standard-21-0.14.noarch conflicts fedora-release-workstation --> Finished Dependency Resolution --> Running transaction check ---> Package fedora-release-workstation.noarch 0:21-0.13 will be updated ---> Package fedora-release-workstation.noarch 0:21-0.13 will be updated ---> Package fedora-release-workstation.noarch 0:21-0.13 will be updated ---> Package fedora-release-workstation.noarch 0:21-0.13 will be updated ---> Package fedora-release-workstation.noarch 0:21-0.13 will be updated ---> Package kde-l10n-British.noarch 0:4.14.2-1.fc21 will be installed --> Processing Dependency: kde-l10n = 4.14.2-1.fc21 for package: kde-l10n-British-4.14.2-1.fc21.noarch --> Running transaction check ---> Package kde-l10n.noarch 0:4.14.2-1.fc21 will be installed --> Processing Conflict: fedora-release-workstation-21-0.14.noarch conflicts fedora-release-standard --> Processing Conflict: fedora-release-workstation-21-0.14.noarch conflicts fedora-release-standard --> Processing Conflict: fedora-release-standard-21-0.14.noarch conflicts fedora-release-workstation --> Processing Conflict: fedora-release-standard-21-0.14.noarch conflicts fedora-release-workstation --> Finished Dependency Resolution Error: fedora-release-workstation conflicts with fedora-release-standard-21-0.14.noarch Error: fedora-release-standard conflicts with fedora-release-workstation-21-0.14.noarch You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest
I forgot to mention that the install dvd is the Alpha release.
I still get this problem when installing Fedora-Live-Workstation-x86_64-21_Beta-1.iso: [mfabian@localhost ~]$ LANG=en_GB.UTF-8 sudo yum groupinstall xfce-desktop-environment ... ---> Package libxml++.x86_64 0:2.37.1-3.fc21 will be installed --> Processing Conflict: fedora-release-workstation-21-0.16.noarch conflicts fedora-release-nonproduct --> Processing Conflict: fedora-release-workstation-21-0.16.noarch conflicts fedora-release-nonproduct --> Processing Conflict: fedora-release-nonproduct-21-0.16.noarch conflicts fedora-release-workstation --> Finished Dependency Resolution 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 You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest [mfabian@localhost ~]$
This is because the environment groups explicitly list 'fedora-release-nonproduct' as a required component. Environment groups are really supposed to be for Anaconda's use (though over time they have grown into more general usage). I don't believe that comps.xml (or yum/dnf) has any support for conditionals (i.e. fedora-release-nonproduct if none of the others is already installed). So without that, we're limited in what we can do. The workaround of course would be to create a standard yum group that is equivalent to the current environments except for the presence of the release package. Then we would just tell people to use the @xfce-desktop group instead of the @^xfce-desktop-environment environment group when installing on a productized system. It's not a perfect solution, but for F21 it's probably the only technically-feasible one.
it would help to be able to set different user-visibility statuses for install-time and post-install. then we could have only the group with the product package in it visible at install time, and only the group *without* it visible post-install.
hum, forgot this one existed when filing 1160917...
Still an issue with official release. Is there a workaround after install?
It's listed in the common bugs entry. 'yum groupinstall (foo) --skip-broken'. Note, must use 'groupinstall', not 'group install' (they hit different codepaths in yum, believe it or not).
I've been working on an alternate approach to solving this that won't rely on package manager esoterica. The new approach will be to have /etc/os-release optionally contain a VARIANT= value if one of the Editions was installed. Then, any package that needs product-specific functionality should check for that in %posttrans and set the right configuration there. One DNF issue is blocking this, which I am linking here.
For the record, the mechanism to change to /etc/os-release is proposed here[1] and the latest version of the patch at the time of this writing is here [2]. [1] https://lists.fedoraproject.org/pipermail/rel-eng/2015-March/019498.html [2] https://lists.fedoraproject.org/pipermail/rel-eng/2015-March/019527.html
I've also submitted a backport patch for Fedora 22 here[3] [3] https://lists.fedoraproject.org/pipermail/rel-eng/2015-March/019569.html
This should be fixed in Rawhide as of fedora-productimg-server-22-7.fc22 (Around March 17th) We still need this backported to Fedora 22 for Beta. Due to timing mistakes, some dependent components (firewalld) have already been pushed to stable on that branch.
Is this still something we want to backport to f22? Or should we just close it since f23+ should be fixed?
(In reply to Kevin Fenzi from comment #16) > Is this still something we want to backport to f22? > > Or should we just close it since f23+ should be fixed? This is already fixed in F22. Did you mean to ask if it should be backported to F21?
(In reply to Stephen Gallagher from comment #17) > (In reply to Kevin Fenzi from comment #16) > > Is this still something we want to backport to f22? > > > > Or should we just close it since f23+ should be fixed? > > This is already fixed in F22. Did you mean to ask if it should be backported > to F21? Sorry, I just reread the comments above and noticed that this was just never updated once we did the backport. Whoops. Yeah, this is all fixed in F22 already.
Great. Closing then. :)