Bug 609224 - libjpeg-turbo needs to properly provide/obsolete libjpeg
Summary: libjpeg-turbo needs to properly provide/obsolete libjpeg
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: libjpeg-turbo   
(Show other bugs)
Version: rawhide
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Adam Tkac
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords:
: 609366 609637 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-06-29 17:21 UTC by Deji Akingunola
Modified: 2014-01-21 23:15 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-07-02 09:00:17 UTC
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 15:16 UTC, Horst H. von Brand
no flags Details

Description Deji Akingunola 2010-06-29 17:21:05 UTC
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 05:56:11 UTC
*** Bug 609366 has been marked as a duplicate of this bug. ***

Comment 2 Rex Dieter 2010-07-01 02:57:43 UTC
*** Bug 609637 has been marked as a duplicate of this bug. ***

Comment 3 Rex Dieter 2010-07-01 03:00:45 UTC
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-07-01 03:10:02 UTC
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-07-01 03:29:17 UTC
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-07-01 03:36:06 UTC
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-07-01 03:57:13 UTC
Re: comment #4
I get:  
0:libjpeg-turbo-0.0.93-10.fc14.i686

Comment 8 Dennis Gilmore 2010-07-01 03:59:36 UTC
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 14:39:32 UTC
(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 14:46:23 UTC
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 15:03:41 UTC
(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 15:07:58 UTC
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 15:16:13 UTC
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 16:06:59 UTC
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 18:39:41 UTC
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 09:00:17 UTC
(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 11:35:46 UTC
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.