Currently digikam 0.9.0 uses an internal copy of dcraw (8.41), but dcraw is set as a dependancy (and this dependancy is not needed). I think it could be better to use the portage copy of dcraw instead to have many copies of this program, even if it's small. So follow patch against digikam-0.9.0 and its ebuild do disable building and usage of the internal copy.
Created attachment 109106 [details, diff] digikam-0.9.0-external-dcraw.patch Patch to disable usage of internal dcraw copy
Created attachment 109107 [details, diff] digikam-0.9.0.patch patch against digikam ebuild to update the dcraw dependancy (digikam 0.9.0 works only with dcraw >= 8.40 command line interface) and add the patch.
As stated in those comments, the dcraw author broke backwards compatibility with that library. We'll simply drop the use flag for now.
Sorry, I do not agree. Job of a package managing system is to manage depandencies but ALSO to avoid unusefull duplications of binaries. When dcraw will have a bug : you will bump digikam, kipi-plugins, dcraw itself and all other programs using an internal copy of dcraw instead of only one package ? An other interest of using external dcraw : new version provides new support (Pentax K10D for example, recently added) and not supported by digikam internal copy of dcraw. In fact, it's just the same debate as dynamic vs static libraries, or just like the same work done by flameeyes on ffmpeg to avoid multiple internal copies on the tree and use only one external ffmpeg version... Maintaining backaward compatibility of dcraw for those programs using dcraw is easy, and IS the job of a package managing system (or if you do not want to upgrade, backport fixes...). As an example here is the patch to maintain backward compatibility of dcraw (last version) against digikam and kipi-plugins (both patched for using external copy of dcraw of course) : http://gentoo.xwing.info/media-gfx/dcraw/files/dcraw-8.62-backward-compat.patch As you want, I will continue to maintain it in my overlay. But I continue to think that it could be a very good improvement in portage... Cheers
(In reply to comment #4) > Sorry, I do not agree. > Job of a package managing system is to manage depandencies but ALSO to avoid > unusefull duplications of binaries. When dcraw will have a bug : you will bump > digikam, kipi-plugins, dcraw itself and all other programs using an internal > copy of dcraw instead of only one package ? In general yes, valid exceptions exist. The above mentioned packages will rely ony libkdcraw¹ in future, when you can trust upstream. And while we're at it: It is absolutely not interesting that there is yet another small binary on your precious multi-gigabyte-harddisk. The relevant problem is that, in case of vulerabilities, multiple packages have to be, tracked, fixed, advisories to be written, etc.. > An other interest of using external dcraw : new version provides new support > (Pentax K10D for example, recently added) and not supported by digikam internal copy of dcraw. Pointless, when the interface gets changed constantly so the application using dcraw doesn't know how to deal with the new one. [1] http://www.digikam.org/?q=node/208