Bug 609224 - libjpeg-turbo needs to properly provide/obsolete libjpeg
libjpeg-turbo needs to properly provide/obsolete libjpeg
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: libjpeg-turbo (Show other bugs)
rawhide
All Linux
low Severity medium
: ---
: ---
Assigned To: Adam Tkac
Fedora Extras Quality Assurance
:
: 609366 609637 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-06-29 13:21 EDT by Deji Akingunola
Modified: 2014-01-21 18:15 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-07-02 05:00:17 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Output from "yum -d7 update --skip-broken" (194.29 KB, text/plain)
2010-07-01 11:16 EDT, Horst H. von Brand
no flags Details

  None (edit)
Description Deji Akingunola 2010-06-29 13:21:05 EDT
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:
Comment 1 ritz 2010-06-30 01:56:11 EDT
*** Bug 609366 has been marked as a duplicate of this bug. ***
Comment 2 Rex Dieter 2010-06-30 22:57:43 EDT
*** Bug 609637 has been marked as a duplicate of this bug. ***
Comment 3 Rex Dieter 2010-06-30 23:00:45 EDT
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@fedoraproject.org. 0.9.93-12
- move Obsoletes: libjpeg to main pkg

* Wed Jun 30 2010 Rex Dieter <rdieter@fedoraproject.org> 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?
Comment 4 seth vidal 2010-06-30 23:10:02 EDT
with your new pkgs in a repo - if you run:

yum resolvedep libjpeg.so.62

what pkg does it return?
Comment 5 Tom Lane 2010-06-30 23:29:17 EDT
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.
Comment 6 Tom Lane 2010-06-30 23:36:06 EDT
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.
Comment 7 Rex Dieter 2010-06-30 23:57:13 EDT
Re: comment #4
I get:  
0:libjpeg-turbo-0.0.93-10.fc14.i686
Comment 8 Dennis Gilmore 2010-06-30 23:59:36 EDT
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.
Comment 9 Horst H. von Brand 2010-07-01 10:39:32 EDT
(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
Comment 10 Rex Dieter 2010-07-01 10:46:23 EDT
Interesting, my value in comment #7 was run on my f13 box via
yum --disablerepo=\* --enablerepo=rawhide ...
Comment 11 Horst H. von Brand 2010-07-01 11:03:41 EDT
(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
Comment 12 seth vidal 2010-07-01 11:07:58 EDT
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'.
Comment 13 Horst H. von Brand 2010-07-01 11:16:13 EDT
Created attachment 428468 [details]
Output from "yum -d7 update --skip-broken"

x86_64 rawhide, yum-3.2.27-17.fc14.noarch
Comment 14 seth vidal 2010-07-01 12:06:59 EDT
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?
Comment 15 Terje Røsten 2010-07-01 14:39:41 EDT
With Rex' change 

* Wed Jun 30 2010 Rex Dieter <rdieter@fedoraproject.org. 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...
Comment 16 Adam Tkac 2010-07-02 05:00:17 EDT
(In reply to comment #15)
> With Rex' change 
> 
> * Wed Jun 30 2010 Rex Dieter <rdieter@fedoraproject.org. 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.
Comment 17 Adam Tkac 2010-07-02 07:35:46 EDT
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.

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