[Pkg-phototools-devel] Bug#553359: Upstream packaging

[Pascal de Bruijn]

On Sat, Jul 24, 2010 at 5:14 PM, Bernd Zeimetz <bernd at bzed.de> wrote:
> On 07/24/2010 04:48 PM, Bernd Zeimetz wrote:
>> Hi Pascal!
>>
>> On 07/24/2010 12:25 PM, Pascal de Bruijn wrote:
>>> I think most licensing issues have been resolved upstream.
>>
>> I'll have a look :)
>
> So basically the only thing that makes my head ache is the embedded copy of libraw:
> - it is an embedded source copy, such things are always bad, especially when it
> comes to security issues. Also the license information for files like
> ahd_interpolate_mod.c/ahd_partial_interpolate.c was lost as the libraw project's
> license information is not available.

Ok, I assumed the copyright issue was about the icc files, I'll ask
the developers to look into the .c files.

But, embedding LibRaw is quite important... Using a external copy
entail too much practical issues:

1. When people report raw reading bugs about Darktable 0.6 (for
example), we have no easy way to know which LibRaw version was linked
against.
2. We sometimes have local patches to LibRaw, which can be quite
important... In the past the very important Green Channel
Equibrilation was locally patched (which took a few month's to go
upstream to LibRaw (now in 0.10)), and now we have a Canon EOS 40D
Rotation patch locally applied. Which is important as well, since the
40D is a _very_ popular camera, and we already have multiple 40D
users.

So linking against a system LibRaw copy, will in general frustrate
development and troubleshooting.

Please also note, others RAW converters like UFRaw also have their own
dcraw copy embedded, they libified it themselves. So in all regards we
are no worse or better than UFRaw in this respect.

> - it comes with automatically generated files without any way to recreate them
> (guess that is in the original libraw source, but you can't assume that somebody
> who receives the darktable source also receives the libraw source).

I'm not sure I understand... I think we have a full copy of LibRaw in
a source tree, so this shouldn't be a problem?

> Uploading the source as it is now would clearly give a REJECT from the
> ftp-masters. The best way for me would be to modify the autotools stuff in a way
> that it will only use the embdeeded copy of libraw if the folder is there,
> otherwise use the version which is installed in the system. Then we could just
> remove that folder and use libraw from Debian. Ensuring that libraw in Debian is
> uptodate is no problem at all.

Again, I disagree that we should use a system libraw copy...

I'd like to emphasize rejecting Darktable for this, and allowing UFRaw
would be very silly at best.

And with regards to keeping LibRaw up to date, this isn't per-se the
issue, since Darktable may require a specific version of LibRaw, and
other raw converter might require a different version, which means
that one would need multiple system (packaged) copies of LibRaw.

Please don't get me wrong, in general I do agree with the policy that
keeping local copies of library is a very bad idea. I just think this
policy applies poorly to LibRaw at this point.

I think there are some changes planned regarding LibRaw for after 0.6,
that would make using a system copy of libraw a bit more viable, so
this can be rediscussed in the future.

Regards,
Pascal de Bruijn