Just a small remark at the beginning: I didn't meant dcraw upstream with "dcraw guys" but the Debian maintainers for dcraw. And I really think it is a good question because the package is dead since 3 years and missing some updates from upstream.
(Ok, the embedded copy of dcraw in exactimage seems to be older)
On Sunday 09 June 2013 19:37:03 Rene Rebe wrote:
> I think dcraw did all the original research and he does not want to make it
> a library because he believes an executable to call is the unix way and a
> library he could boy change so flexible. This is why I embedded the not too
> big code to make it a simple built in library inside exact image.
This is correct, but is not really about the problem here. Just to give more
insight in what Mathieu Malaterre said:
Embedded copies of code are bad when used in Distributions because (just some
examples):
* they increase the binary size when there would be shared object that could
be used instead
* they increase memory usage because different programs cannot share the
loaded library
* they are hard to maintain
Ok, the first two points are easy to understand but the last one might be
quite vague. So here an explanation with two different scenarios (actually it
is the same example but with different impacts):
dcraw gets a new version (lets call it 9.18 for obvious reasons) with X-Trans
and EOS C500 support. Now all programs using an embedded copy have to be
updated in Debian to bring these versions on par with the upstream one and fix
outstanding bugs/request for EOS C500/X-Trans. This is not really trivial
because the programs have to be identified first and then the maintainer has
to be waken up. This is a lot of work and time spend on a task that is
completely unnecessary. Therefore, it is better to use the library version
when available. And yes, I am fully aware that interface changes are problems
which can be a negative effect when switching to external libraries.
Now to the part with a little more impact. Lets assume that dcraw has a bug
which can be exploited quite easily (send a prepared image which causes some
buffer overflows and so on). Now it is extreme important to find all versions
of the embedded copy because otherwise it is a security risk. You don't really
want to provide an web service doing raw image conversions when there might be
a big security hole because the security bug was fixed in the original
program/library but not in the embedded copy.
So back to the main questions. Do you see a possible way to switch from your
dcraw version to libraw and make more of the embedded copies optional? I know,
the embedded copies from libjpeg for jpeg rotation are for example really hard
because libjpeg doesn't export the necessary stuff. But it seemed to have
caused some headaches for the previous maintainers of this package because no
one updated the embedded copy of jpegint/transupp and it just crashed when
used together with never versions of libjpeg like libjpeg8. And the current
one in exactimage upstream still does.
Kind regards,
Sven
signature.asc
Description: This is a digitally signed message part.
