Description of problem: Issue is evidently seen at http://koji.fedoraproject.org/koji/getfile?taskID=2280692&name=root.log . The proper obsolete/provide was only done for the -devel sub-packages, however requiring libjpeg-devel is somehow trying to pull in both libjpeg and libjpeg-turbo and thus causing conflict. I guess the problem can also be solved by requesting libjpeg to be removed from the repo. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
*** Bug 609366 has been marked as a duplicate of this bug. ***
*** Bug 609637 has been marked as a duplicate of this bug. ***
As I mentioned in bug #609637 , The Obsoletes/Provides are there, in libjpeg-turbo-utils Obsoletes/Provides: libjpeg and -utils in turn Requires: libjpeg-turbo which should work in theory, but doesn't seem to all that well in practice. I've tried a few adjustments since yesterday to try to help that, %changelog * Wed Jun 30 2010 Rex Dieter <rdieter. 0.9.93-12 - move Obsoletes: libjpeg to main pkg * Wed Jun 30 2010 Rex Dieter <rdieter> 0.0.93-11 - -utils: Requires: %%name ... But no luck so far. Seth? Is this worth worrying about at the yum level, or should we just bite-the-bullet and block/remove libjpeg from rawhide sooner rather than later?
with your new pkgs in a repo - if you run: yum resolvedep libjpeg.so.62 what pkg does it return?
Re comment #3: a package block is a kluge not a fix. The RPM provides/obsoletes need to be fixed, else various update scenarios are going to fail in the field.
FWIW, I think the fundamental mistake here was to try to do two things at once. My suggestion is to drop libjpeg-turbo-utils and just have libjpeg-turbo replacing libjpeg and libjpeg-turbo-devel replacing libjpeg-devel. Sometime in F-15 or later, after all the dust has settled, you can consider splitting libjpeg-turbo into a base package and a utils subpackage --- but doing it right now is biting off more than you can chew. I will also take this opportunity to repeat my opinion that you're going to need libjpeg-turbo-static replacing libjpeg-static, sooner rather than later.
Re: comment #4 I get: 0:libjpeg-turbo-0.0.93-10.fc14.i686
having only the libjpeg-turbo-utils obsoleting libjpeg gausing multilibed updates to fail as experienced on my rawhide machine today. Transaction Check Error: file /usr/lib/libjpeg.so.62.0.0 from install of libjpeg-turbo-0.0.93-10.fc14.i686 conflicts with file from package libjpeg-6b-46.fc12.i686 that is because you only end up getting the 64 bit libjpeg-turbo-utils which is the right thing to do.
(In reply to comment #4) > with your new pkgs in a repo - if you run: > > yum resolvedep libjpeg.so.62 > > what pkg does it return? * rawhide: linux.mirrors.es.net 0 packages excluded due to repository protections 0:libjpeg-6b-46.fc12.i686
Interesting, my value in comment #7 was run on my f13 box via yum --disablerepo=\* --enablerepo=rawhide ...
(In reply to comment #10) > Interesting, my value in comment #7 was run on my f13 box via > yum --disablerepo=\* --enablerepo=rawhide ... Here (x86_64 rawhide, up to date): # yum resolvedep --disablerepo=* --enablerepo=rawhide libjpeg.so.62 Loaded plugins: aliases, auto-update-debuginfo, changelog, downloadonly, : fastestmirror, filter-data, fs-snapshot, keys, list-data, local, : merge-conf, post-transaction-actions, presto, priorities, : protectbase, refresh-packagekit, remove-with-leaves, rpm-warm- : cache, security, show-leaves, tmprepo, tsflags, upgrade-helper, : verify, versionlock Loading mirror speeds from cached hostfile * rawhide: linux.mirrors.es.net 0 packages excluded due to repository protections 0:libjpeg-6b-46.fc12.i686
I'm a little confused here - can someone post the yum output from the case that is causing the most problem? preferably with yum -d7 I just want to make sure I understand where things are 'failing'.
Created attachment 428468 [details] Output from "yum -d7 update --skip-broken" x86_64 rawhide, yum-3.2.27-17.fc14.noarch
okay I just read through that depsolve output and it appears to be doing EXACTLY what we want it to do. what's the issue?
With Rex' change * Wed Jun 30 2010 Rex Dieter <rdieter. 0.9.93-12 - move Obsoletes: libjpeg to main pkg I was able to update rawhide (multilib system) without any libjpeg* issue, thanks! Why that change was needed is a open issue...
(In reply to comment #15) > With Rex' change > > * Wed Jun 30 2010 Rex Dieter <rdieter. 0.9.93-12 > - move Obsoletes: libjpeg to main pkg > > I was able to update rawhide (multilib system) without any libjpeg* issue, > thanks! > > Why that change was needed is a open issue... Thanks for your feedback. I did another improvement in libjpeg-turbo-0.0.93-13.fc14 (removed unneeded libjpeg provides from -utils subpackage) so this issue is fixed in libjpeg-turbo-0.0.93-13.fc14.
In the end I must have added "Provides: libjpeg" to the main pkg because java-1.6.0-openjdk is still broken (bug #607554) and too many packages depend on it.