Description of problem: libkdcraw have possibility to build optionally internal copy of LibRaw with RawSpeed codec. Now it is possible to build libkdcraw against external LibRaw >= 0.15 but system package LibRaw built without RawSpeed. Looks like RawSpeed disabled at this moment by LibRaw upstream (commented in Makefile) but can we enable it? Version-Release number of selected component (if applicable): LibRaw-0.15.2-1.fc20
The docs mention using RawSpeed/rawspeed.cpucount-unix.patch, which applies against a file not present in LibRaw. RawSpeed is not in Fedora, and I can't find a release available, except as part of rawstudio, which is in Fedora, but without RawSpeed. Adding rawstudio maintainer. Since rawstudio is the upstream for RawSpeed, and LibRaw wants a patch applied to RawSpeed, it seems that the best path forward would be to package RawSpeed applying the LibRaw patch, add that to Fedora, and have LibRaw then build with that. The problem is there don't seem to be releases, only svn: http://rawstudio.org/svn/rawspeed/ Which I can't figure out how to build, and http://rawstudio.org/svn/rawstudio/trunk/plugins/load-rawspeed/ Which is part of rawstudio, but might provide guidance on how to build it. All in all, it look like a non-trivial effort, and with no upstream releases we'd have to decide on our own soname, and decide when to increment it. Gianluca, to you have anything to add to this?
I think you're expected to add RawSpeed to the LibRaw build tree and then build the whole thing as one library. At least that's how libkdcraw does/did it.
That was my understanding as well. But if the only way to add RawSpeed support is to bundle it, I'll pass. That's why I was soliciting alternative suggestions.
Well, "bundling" is not the right term here. RawSpeed is not a standalone library, it's a "patch" for LibRaw (mostly constituted of added files, though as I understand it, some other LibRaw code is then not used, replaced by the RawSpeed code).
If it's outright replacing LibRaw code, then it's a fork.
And the point of this request is that we should be packaging RawSpeed-enhanced LibRaw rather than stock LibRaw, just as we're packaging, e.g., libjpeg-turbo rather than IJG libjpeg.
Ok, that's a different issue. But I'm still not convinced. What benefits does that bring us over LibRaw that justify moving from a project with stable releases to a fork that doesn't seem to offer them?
rawstudio guys seem active but they have done less and less releases lately, relying on some ppa for their primary distribution. However, reading all of this I tend to think either a proper librawspeed fork emerges, or rawstudio guys submits their patches upstream. As is, I don't think there is much space to make a package for librawspeed: too much downstream work to make it useful.
My thoughts exactly. Feel free to reopen when either a fork is released or this is released buildable upon existing LibRaw.