Bug 887013

Summary:	libjpeg-turbo-compat isn't very compat because of ill-considered use of subdirectories
Product:	[Fedora] Fedora	Reporter:	Tom Lane <tgl>
Component:	libjpeg-turbo-compat	Assignee:	Adam Tkac <atkac>
Status:	CLOSED RAWHIDE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	rawhide	CC:	atkac, bgilbert, hhorak, orion, ovasik, rc040203
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-12-17 12:37:09 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Tom Lane 2012-12-13 20:14:29 UTC

Description of problem:
As of current rawhide, libtiff fails to build, with complaints like
raw_decode.c:45:55: fatal error: jpeglib.h: No such file or directory

It appears that "BuildRequires: libjpeg-devel" now pulls in libjpeg-turbo-compat, which does indeed provide jpeglib.h ... but it puts it in some random subdirectory where calling applications won't find it.

I am not aware that it's considered good enough for a compatibility package if calling apps have to be significantly modified to compile against it.

Version-Release number of selected component (if applicable):
libjpeg-turbo-compat.1.2.1-5.fc19

How reproducible:
I get this in mock with fedora-rawhide config.  Koji shows a different failure that I don't understand entirely --- it compiles (how?) but fails at runtime, probably because the .so has also been dropped into a random subdirectory where the dynamic linker can't find it either.  That's definitely a packaging bug, even if you try to tell me the include-file breakage is all right.  Koji build failure can be seen at
http://koji.fedoraproject.org/koji/taskinfo?taskID=4787625

Additional info:
I think you'd be better advised to make the new-API version of the library be the one with headers in a nonstandard place, since callers will need changes anyway if they want to use that.

Comment 1 Orion Poplawski 2012-12-13 22:09:57 UTC

I think libjpeg-devel should pull in libjpeg-turbo-devel, the new API in the standard location.  I someone can't port to the new API they can then use the old one.  My one package built unchanged against the new one.

Comment 2 Tom Lane 2012-12-13 22:49:22 UTC

(In reply to comment #1)
> I think libjpeg-devel should pull in libjpeg-turbo-devel, the new API in the
> standard location.

If the new API is source-level-compatible for most apps, that would be a sensible approach.  Recompile and you're suddenly using jpeg8.  If that fails, and you don't want to spend time fixing it right away, repoint your BuildRequires at libjpeg-turbo-compat-devel.

I think this solution would require making libjpeg-turbo-compat-devel Conflict: with libjpeg-turbo-devel, since they'd both be wanting to install jpeglib.h in /usr/include.  But that seems all right to me; preferable anyway to asking people to monkey with their source code when the whole point is that they don't want to.  As long as the base packages can be installed concurrently, we don't need the devel packages to be.

Comment 3 Adam Tkac 2012-12-17 10:35:43 UTC

*** Bug 887549 has been marked as a duplicate of this bug. ***

Comment 4 Adam Tkac 2012-12-17 11:16:54 UTC

In my opinion removal of libjpeg-devel Obsoletes/Provides from libjpeg-turbo-compat-devel should be sufficient to fix this issue.

Comment 5 Adam Tkac 2012-12-17 11:20:15 UTC

(In reply to comment #4)
> In my opinion removal of libjpeg-devel Obsoletes/Provides from
> libjpeg-turbo-compat-devel should be sufficient to fix this issue.

On second though libjpeg-turbo-compat even doesn't have to provide libjpeg because -compat pkg will be pulled-in via rpm-build generated libjpeg.so.6() dependency.

Comment 6 Adam Tkac 2012-12-17 12:37:09 UTC

Should be fixed in libjpeg-turbo-compat-1.2.1-6.fc19