Bug 1146487 - F21: installing non-Product environment groups in Product installs fails due to fedora-release-(product) vs. fedora-release-standard conflict
Summary: F21: installing non-Product environment groups in Product installs fails due ...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: comps
Version: 21
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Stephen Gallagher
QA Contact:
URL:
Whiteboard:
Depends On: 1160917
Blocks: 1167881 1192225 1204739
TreeView+ depends on / blocked
 
Reported: 2014-09-25 10:27 UTC by Mike FABIAN
Modified: 2015-07-16 23:49 UTC (History)
16 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-07-16 23:49:42 UTC
Type: Bug


Attachments (Terms of Use)

Description Mike FABIAN 2014-09-25 10:27:37 UTC
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)

Comment 1 Stephen Gallagher 2014-10-06 12:42:01 UTC
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.

Comment 2 Mike FABIAN 2014-10-08 11:27:24 UTC
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.

Comment 3 Adam Williamson 2014-10-09 20:10:26 UTC
"'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.

Comment 4 Kristjan Stefansson 2014-10-18 01:35:54 UTC
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

Comment 5 Kristjan Stefansson 2014-10-18 14:51:12 UTC
I forgot to mention that the install dvd is the Alpha release.

Comment 6 Mike FABIAN 2014-10-27 08:59:26 UTC
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 ~]$

Comment 7 Stephen Gallagher 2014-10-27 12:07:36 UTC
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.

Comment 8 Adam Williamson 2014-10-27 15:28:32 UTC
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.

Comment 9 Adam Williamson 2014-11-07 01:11:37 UTC
hum, forgot this one existed when filing 1160917...

Comment 10 Rick Dicaire 2014-12-15 15:27:45 UTC
Still an issue with official release.

Is there a workaround after install?

Comment 11 Adam Williamson (Fedora) 2014-12-15 17:53:25 UTC
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).

Comment 12 Stephen Gallagher 2015-03-12 20:59:28 UTC
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.

Comment 13 Stephen Gallagher 2015-03-12 21:00:29 UTC
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

Comment 14 Stephen Gallagher 2015-03-16 15:30:56 UTC
I've also submitted a backport patch for Fedora 22 here[3]

[3] https://lists.fedoraproject.org/pipermail/rel-eng/2015-March/019569.html

Comment 15 Stephen Gallagher 2015-03-23 14:07:13 UTC
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.

Comment 16 Kevin Fenzi 2015-07-15 20:23:34 UTC
Is this still something we want to backport to f22?

Or should we just close it since f23+ should be fixed?

Comment 17 Stephen Gallagher 2015-07-16 12:36:19 UTC
(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?

Comment 18 Stephen Gallagher 2015-07-16 12:37:12 UTC
(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.

Comment 19 Kevin Fenzi 2015-07-16 23:49:42 UTC
Great. Closing then. :)


Note You need to log in before you can comment on or make changes to this bug.