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.
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.
(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.
*** Bug 887549 has been marked as a duplicate of this bug. ***
In my opinion removal of libjpeg-devel Obsoletes/Provides from libjpeg-turbo-compat-devel should be sufficient to fix this issue.
(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.
Should be fixed in libjpeg-turbo-compat-1.2.1-6.fc19