Description of problem: I want to use fedup to upgrade my system from Fedora 20 to Fedora 21. 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. Version-Release number of selected component (if applicable): $ rpm -qa | grep fedora-release fedora-release-20-3.noarch fedora-release-notes-20-0.9.noarch fedup-0.9.1-1.fc20.noarch How reproducible: 100% previously I did a groupinstall of "MATE Desktop"
Can you attach fedup.log? For best results, get a fresh log: sudo fedup --network 21 --product=workstation --debuglog=~/fedup.log then upload ~/fedup.log. But your existing /var/log/fedup.log will do otherwise.
Created attachment 969787 [details] fedup log here's the log
Want me to open a bug for this too? Doesn't seem to be able to translate ~ to home dir... $ sudo fedup --network 21 --product=workstation --debuglog=~/fedup.log Traceback (most recent call last): File "/bin/fedup", line 280, in <module> logutils.debuglog(args.debuglog) File "/usr/lib/python2.7/site-packages/fedup/logutils.py", line 49, in debuglog h = logging.FileHandler(filename) File "/usr/lib64/python2.7/logging/__init__.py", line 902, in __init__ StreamHandler.__init__(self, self._open()) File "/usr/lib64/python2.7/logging/__init__.py", line 925, in _open stream = open(self.baseFilename, self.mode) IOError: [Errno 2] No such file or directory: '/home/jp/~/fedup.log'
Will: I think I figured out the corner case John hit, I'm not sure there's much fedup could necessarily do about it. See https://bugzilla.redhat.com/show_bug.cgi?id=1160917#c15 .
(In reply to John Poelstra from comment #3) > Want me to open a bug for this too? Doesn't seem to be able to translate ~ > to home dir... > > $ sudo fedup --network 21 --product=workstation --debuglog=~/fedup.log Please don't. Interpreting ~ and ~user is a shell feature. It's done if the tilde is in the beginning of the argument. The preceding "=" prevented it. Replace it with a space to allow expansion. Other utilities are not supposed to do tilde expansion. That would be the second tilde expansion in addition to the one done by the shell. Maybe ask bash developers to do tilde expansion after "--foo="; long options are a GNU feature after all. Sorry for offtopic.
(In reply to John Poelstra from comment #3) > Want me to open a bug for this too? Doesn't seem to be able to translate ~ > to home dir... Oh, hrm, yeah - at the very least fedup shouldn't trace back there. If you'd be so kind as to open a bug, that'll help remind me to fix it. (In reply to Adam Williamson (Red Hat) from comment #4) > Will: I think I figured out the corner case John hit, I'm not sure there's > much fedup could necessarily do about it. See > https://bugzilla.redhat.com/show_bug.cgi?id=1160917#c15 . So this seems to be a legit package conflict: you can't use '--product workstation' because MATE (currently) conflicts with it. (Like if MATE were its own product.) The error message doesn't make this root cause super-clear, but that's mostly because it's not obvious to fedup *why* fedora-release-nonproduct is being installed. The only thing about it in fedup.log is: fedup.depsolve:pkgAdded() fedora-release-nonproduct-21-2.noarch: install (install) ...with no mention of what package/group pulled that in. I guess we shouldn't require '--product' if it turns out that the upgrade transaction would already install a product for you, but at the moment I don't have a clear way to determine which group is implicitly declaring itself to be a "product" by (paradoxically) including the "nonproduct" product package. So: without a well-defined policy for how things define themselves to be products, I'm not sure what more fedup can do in this case?
well, AFAICS the policy is 'all environment groups must pull in a product package'. I believe comps-f21.xml.in conforms to this. So you could try something like 'if yum considers any environment group to be installed, don't require --product, and if it's passed, warn the user that it won't be used and ask whether they want to proceed'? Assuming we can rely on this 'pull in extra packages from installed env groups' logic *always* applying. Then we'd have to change the docs, of course... unforutnately sgallagh explains to me that fedora-release-nonproduct is needed apparently to make sure when we have per-product configuration packages, foo-config-nonproduct is installed. Somehow the existence of -release-nonproduct will cause the matching -config package to be installed, but without it you'll get something yum chooses, or something. Don't ask me, I'm just the monkey. Apparently depsolver improvements are coming for F23 to make this unnecessary.
additionally, as none of the Product envs exist in F20, if an env group is installed, you can tell the user that the upgraded system will be a 'non-Product' install - I think it'll definitely always be fedora-release-nonproduct that gets pulled in this way, when this condition happens.
Okay so, as I understand it, this is the situation: * F20 systems may have one or more Environment Group installed. * F21 Environment Groups all include one of four Products. * F21 systems must have one (and only one) Product. As mandated by the Product folks, fedup requires "--product" on upgrades to F21, because there was (apparently) no way to figure out a default product. So if the above is correct, any system with an Environment Group installed will have the corresponding Product pulled into the transaction by yum. Which would yield one of two situations: 1) One Environment Group is installed, or multiples using the same Product) A Product is added automatically, but fedup still requires --product. The upgrade transaction will fail with conflicts if you pick the wrong product. 2) Multiple Environments (with different Products) are installed The upgrade transaction will *always* fail with conflicts. We seem to have hit case #1 here. I haven't seen #2 happen in the wild, yet.
That's mostly correct as I understand it, yes, with one additional thing that may be useful and affects #2: * The Environment Groups that pull in fedora-release-workstation, fedora-release-server, and fedora-release-cloud are all new in F21. No Environment Group that existed in F20 will pull in any of those. I also just thought of something else, though. One environment group was removed between 20 and 21: gnome-desktop-environment. So if you have that one installed, when you run fedup, you won't get a Product package pulled in by the env group. If you have any *other* env group installed, you will get fedora-release-nonproduct in the upgrade transaction. #2 is never going to happen because of the additional note. Even if you had every single environment group installed, the only product package that gets pulled in via the groups will be fedora-release-nonproduct.
I just ran into this too. I think the upgrade itself went okay, but now whenever I do 'yum update' it complains that it wants to install fedora-release-nonproduct and can't because of a conflict. I'm guessing Xfce is the problem on my machine: [root@grograman]# yum update Loaded plugins: auto-update-debuginfo, fastestmirror, langpacks, priorities, protectbase, versionlock Loading mirror speeds from cached hostfile * fedora: www.gtlib.gatech.edu * fedora-debuginfo: www.gtlib.gatech.edu * rpmfusion-free: mirror.nexcess.net * rpmfusion-free-debuginfo: mirror.nexcess.net * rpmfusion-free-updates: mirror.nexcess.net * rpmfusion-free-updates-debuginfo: mirror.nexcess.net * rpmfusion-nonfree: mirror.nexcess.net * rpmfusion-nonfree-debuginfo: mirror.nexcess.net * rpmfusion-nonfree-updates: mirror.nexcess.net * rpmfusion-nonfree-updates-debuginfo: mirror.nexcess.net * updates: www.gtlib.gatech.edu * updates-debuginfo: www.gtlib.gatech.edu 0 packages excluded due to repository protections Resolving Dependencies --> Running transaction check ---> Package fedora-release-nonproduct.noarch 0:21-2 will be installed --> Processing Conflict: fedora-release-workstation-21-2.noarch conflicts fedora-release-nonproduct --> Processing Conflict: fedora-release-nonproduct-21-2.noarch conflicts fedora-release-workstation --> Finished Dependency Resolution Error: fedora-release-nonproduct conflicts with fedora-release-workstation-21-2.noarch Error: fedora-release-workstation conflicts with fedora-release-nonproduct-21-2.noarch You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest [root@grograman rc.d]# rpm -qa | grep fedora-release fedora-release-workstation-21-2.noarch fedora-release-21-2.noarch fedora-release-notes-21.08-1.fc21.noarch [root@grograman]# yum grouplist Loaded plugins: auto-update-debuginfo, fastestmirror, langpacks, priorities, protectbase, versionlock Loading mirror speeds from cached hostfile * fedora: www.gtlib.gatech.edu * fedora-debuginfo: www.gtlib.gatech.edu * rpmfusion-free: mirror.nexcess.net * rpmfusion-free-debuginfo: mirror.nexcess.net * rpmfusion-free-updates: mirror.nexcess.net * rpmfusion-free-updates-debuginfo: mirror.nexcess.net * rpmfusion-nonfree: mirror.nexcess.net * rpmfusion-nonfree-debuginfo: mirror.nexcess.net * rpmfusion-nonfree-updates: mirror.nexcess.net * rpmfusion-nonfree-updates-debuginfo: mirror.nexcess.net * updates: www.gtlib.gatech.edu * updates-debuginfo: www.gtlib.gatech.edu 0 packages excluded due to repository protections Installed environment groups: KDE Plasma Workspaces Xfce Desktop Development and Creative Workstation Web Server Minimal Install gnome-desktop-environment Available environment groups: Fedora Server Fedora Workstation Fedora Cloud Server LXDE Desktop Cinnamon Desktop MATE Desktop Sugar Desktop Environment Infrastructure Server Basic Desktop Installed groups: Administration Tools Authoring and Publishing C Development Tools and Libraries Cloud Infrastructure Design Suite Development Tools Editors Educational Software Engineering and Scientific Fedora Eclipse Games and Entertainment LibreOffice Network Servers Office/Productivity RPM Development Tools Sound and Video System Tools Text-based Internet Available Groups: 3D Printing Audio Production Books and Guides Cloud Management Tools Cloud Server Tools Container Management D Development Tools and Libraries Domain Membership Electronic Lab FreeIPA Server Headless Management MATE Applications MATE COMPIZ Medical Applications Milkymist Robotics Security Lab Window Managers Done
This message is a reminder that Fedora 20 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 20. 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 '20'. 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 20 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 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 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.