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:
yum update gnome-vfs2 -y
Loaded plugins: langpacks, priorities
--> 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
Package Arch Version Repository Size
gnome-vfs2 i686 2.24.4-15.fc21 rawhide 838 k
gnome-vfs2 x86_64 2.24.4-15.fc21 rawhide 812 k
Upgrade 2 Packages
Total size: 1.6 M
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
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
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.
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
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
yielded bogus results on x86_64 near the f21 mass rebuild (seems fixed now).
* Wed Dec 03 2014 Rex Dieter <firstname.lastname@example.org> - 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 <email@example.com> 2.24.4-17
- rebuild (#1109477)
gnome-vfs2-2.24.4-17.fc21 has been submitted as an update for Fedora 21.
(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.
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
* 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:
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.