Description of problem: yum update gnome-vfs2 -y Version-Release number of selected component (if applicable):gnome-vfs2-2.24.4-15.fc21 How reproducible: yum update -y Steps to Reproduce: 1. yum update gnome-vfs2 -y Loaded plugins: langpacks, priorities Resolving Dependencies --> Running transaction check ---> Package gnome-vfs2.i686 0:2.24.4-14.fc21 will be updated ---> Package gnome-vfs2.x86_64 0:2.24.4-14.fc21 will be updated ---> Package gnome-vfs2.i686 0:2.24.4-15.fc21 will be an update ---> Package gnome-vfs2.x86_64 0:2.24.4-15.fc21 will be an update --> Finished Dependency Resolution Dependencies Resolved ============================================================================================ Package Arch Version Repository Size ============================================================================================ Updating: gnome-vfs2 i686 2.24.4-15.fc21 rawhide 838 k gnome-vfs2 x86_64 2.24.4-15.fc21 rawhide 812 k Transaction Summary ============================================================================================ Upgrade 2 Packages Total size: 1.6 M Downloading packages: Running transaction check Running transaction test Transaction check error: file /etc/gconf/schemas/desktop_gnome_url_handlers.schemas conflicts between attempted installs of gnome-vfs2-2.24.4-15.fc21.i686 and gnome-vfs2-2.24.4-15.fc21.x86_64 Error Summary -------------
Happening here as well when trying to upgrade from Fedora 20 to 21: Transaction check error: file /etc/gconf/schemas/desktop_gnome_url_handlers.schemas conflicts between attempted installs of gnome-vfs2-2.24.4-16.fc21.i686 and gnome-vfs2-2.24.4-16.fc21.x86_64
*** Bug 1152038 has been marked as a duplicate of this bug. ***
This has been opened and reproducible since June 2014 and is preventing upgrades to Fedora 21. Raising priority.
can you simply remove the 32 bit version? I'm not sure why it would ever be needed... yum remove gnome-vfs2.i686 Or does that pull something you need?
Unfortunately it is needed by Lotus Notes (argh) client that we extensively use in our company. Basically any GTK 2/gnome 2 program will require this. The fix is to simply mark the schema file as %config in the spec file. Spec attached.
Created attachment 964169 [details] Schema files marked as config
for the record (as someone asked in a releng ticket), this kind of bug doesn't really need to block release. Upgrades usually use the updates/ repository, so we do not need to fix the bug in the frozen release package set. It *is* possible to upgrade using a release medium, but this is rarely done, and will be even more rare with F21+ because we don't have the 'DVD' medium with a fairly broad package set any more. We only have the 'Server DVD', which has a fairly small package set, and so isn't a great thing to run an upgrade with.
(In reply to Adam Williamson (Red Hat) from comment #7) > for the record (as someone asked in a releng ticket), this kind of bug > doesn't really need to block release. Upgrades usually use the updates/ > repository, so we do not need to fix the bug in the frozen release package > set. Sounds reasonable. Then can a provenpackager fix it and create an update ASAP? It's open since June. :) I've added the patched package in a personal repository and had a flawless upgrade to Fedora 21. Thanks.
I can ask for permissions in pkgdb if nobody is willing to maintain it anymore.
I'm not sure using %config here is the best fix, my first question is why do the files differ and conflict in the first place? Once that is known, then some strategies can be forumlated to fix it.
For example, one fix would be to create a common noarch subpkg that contains at least this conflicting file (and koji would enforce that the contents match when built on all archs).
comparing the contents of desktop_gnome_url_handlers.schemas from that on my f20 box, the f21 version misses a bunch of translations.
Looks like a simple rebuild fixes it, I suspect that the hackery in .spec: # strip unneeded translations from .mo files # ideally intltool (ha!) would do that for us # http://bugzilla.gnome.org/show_bug.cgi?id=474987 ... yielded bogus results on x86_64 near the f21 mass rebuild (seems fixed now). %changelog * Wed Dec 03 2014 Rex Dieter <rdieter> - 2.24.4-18 - -common subpkg (#1109477), should ensure koji catches content conflicts - tighten subpkg deps via %%?_isa - %%files: list most files explicitly, less globs - use `pkg-config --variable=includedir smbclient` output instead of hard-coding path - trim %%changelog * Wed Dec 03 2014 Rex Dieter <rdieter> 2.24.4-17 - rebuild (#1109477)
gnome-vfs2-2.24.4-17.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/gnome-vfs2-2.24.4-17.fc21
Cool, thanks.
(In reply to Fedora Update System from comment #14) > gnome-vfs2-2.24.4-17.fc21 has been submitted as an update for Fedora 21. > https://admin.fedoraproject.org/updates/gnome-vfs2-2.24.4-17.fc21 Just noticed the update has a stable karma of 22. Is it a mistake?
probably a mistake, I'll disable autokarma for now, at least until it gets into -testing
Package gnome-vfs2-2.24.4-17.fc21: * should fix your issue, * was pushed to the Fedora 21 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing gnome-vfs2-2.24.4-17.fc21' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-16293/gnome-vfs2-2.24.4-17.fc21 then log in and leave karma (feedback).
gnome-vfs2-2.24.4-17.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.