Summary: | media-gfx/digikam-0.9.0 uses internal copy of dcraw | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Guillaume Castagnino <casta> |
Component: | [OLD] KDE | Assignee: | Ioannis Aslanidis (RETIRED) <deathwing00> |
Status: | VERIFIED WONTFIX | ||
Severity: | enhancement | CC: | kde |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
digikam-0.9.0-external-dcraw.patch
digikam-0.9.0.patch |
Description
Guillaume Castagnino
2007-02-04 12:36:36 UTC
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 |