libjpeg-turbo conflicts in rawhide

Adam Tkac atkac at redhat.com
Thu Jul 1 14:20:33 UTC 2010


On Thu, Jul 01, 2010 at 09:55:08PM +0800, Chen Lei wrote:
> 2010/7/1 Adam Tkac <atkac at redhat.com>:
> > On Tue, Jun 29, 2010 at 11:31:45PM -0400, Rich Mattes wrote:
> >> Hi all,
> >
> > Hello,
> >
> >> I'm trying to build a package that has a BuildRequires: libjpeg-devel in
> >> Rawhide [1].  I get a message in root.log that libjpeg-turbo-devel
> >> obsoletes libjpeg-devel, so yum pulls in libjpeg-turbo-devel instead.
> >> Unfortunately, when it pulls in dependencies for my other BuildRequires,
> >> it's trying to pull in libjpeg and libjpeg-turbo, and I get a conflict
> >> since they both provide libjpeg.so.62.0.0
> >>
> >> The only thing I can think of is that one of the packages I'm requiring
> >> has an explicit dep on libjpeg (I'm about to investigate which).  For
> >> the time being, is there any to work around this?
> >
> > I read this thread and
> > https://bugzilla.redhat.com/show_bug.cgi?id=609224 and I see two
> > reasonable solutions for this problem:
> >
> > 1. Add Obsoletes/Provides libjpeg directly to libjpeg-turbo package
> > which contains only libjpeg.so.62*. I believe this will solve both
> > update and buildroot problems. However it also means all users of
> > libjpeg programs (djpeg, cjpeg and friends) will need to manually
> > install libjpeg-turbo-tools
> >
> > 2. Merge both libjpeg-turbo-utils and libjpeg-turbo to one package, as
> > done in libjpeg.
> >
> > I must admit I like the first solution. People usually needs only
> > libjpeg.so, not programs. People which need libjpeg programs can
> > easily install libjpeg-turbo-tools package themselves, this
> > "incompatibility" seems acceptable for me in development branch.
> >
> > What is your opinion about this proposal?
> >
> > Regards, Adam
> >
> > --
> Only three packages in the rawhide depend on -utils:
> 
> renrot
> gallery2-jpegtran
> gocr

Thanks for your inspection. Those packages can be very
easily fixed by adding "Requires: /usr/bin/djpeg" to them.
This change will be compatible with both former "monolitic" libjpeg
and new libjpeg-turbo-utils. I will do this myself.

Regards, Adam

-- 
Adam Tkac, Red Hat, Inc.


More information about the devel mailing list