[Pkg-phototools-devel] Bug#682980: darktable: should use system shared libraw

[Pascal de Bruijn]

On Sat, Jul 28, 2012 at 6:19 PM, Jonas Smedegaard <dr at jones.dk> wrote:
> [switching to non-quiet flavor of bug address]
>
> On 12-07-28 at 12:09pm, Pascal de Bruijn wrote:
>> On Sat, Jul 28, 2012 at 2:26 AM, Jonas Smedegaard <dr at jones.dk> wrote:
>> > On 12-07-28 at 12:42am, Pascal de Bruijn wrote:
>> >> On Sat, Jul 28, 2012 at 12:28 AM, Jonas Smedegaard <dr at jones.dk>
>> >> wrote:
>> >> > On 12-07-27 at 10:08pm, Pascal de Bruijn wrote:
>> >> >> When Darktable is linked against an external Libraw (or for that
>> >> >> matter RawSpeed) library, we likely would get lots of camera
>> >> >> support bugs which aren't reproducible (assuming the Debian
>> >> >> Libraw version is older), wasting our time. Or we aren't getting
>> >> >> any valid camera support bugs reported (assuming the Debian
>> >> >> Libraw version is newer). So both cases (newer and older) are
>> >> >> detrimental to our project.
>> >> >
>> >> > Bugs from users of Debian should go to Debian for this exact
>> >> > reason: The Debian package maintainers should pass upstream to
>> >> > you the Darktable developers only bugs relevant for you.
>> >>
>> >> Yeah, but that's not reality. People will just come and ask on our
>> >> mailing lists and irc channels, often not telling us they are
>> >> running Debian (unless we specifically ask), wasting our time.
>> >
>> > I recognize that issue from users of Debian reporting bugs about
>> > packages derived from Debian but changed in various ways unknown to
>> > us.
>> >
>> > What I do with that is not try enforce one single use of the
>> > packages we provide, but a) tell our users that they are free to use
>> > Debian also in (to us) weird ways (that's one of the freedoms that
>> > DFSG-free licensing provides!), but b) they are strongly recommended
>> > to tell us very clearly up front when reporting bugs if their setup
>> > of Debian is unusual, to not waste our time e.g. chasing bugs
>> > inefficiently.
>>
>> I guess that's a similar issue.
>>
>> However, there is a difference with users personally modifying things.
>> And distributions shipping non-standard versions.
>>
>> We'd like to make sure that users get a user experience that is
>> representative of our intended Darktable user experience.
>
> Users of Debian are not only personal.  One user of Debian is the
> distribution Ubuntu.

Yes, which multiplies the problem for us. But at least for Ubuntu I
can point people to my Darktable PPAs.

>> >> >> So in my opinion Darktable should get a permanent exception to
>> >> >> this Debian policy.
>> >> >>
>> >> >> PS: Please don't misunderstand, I generally agree with the
>> >> >> policy in this regard, it's just that it makes very little sense
>> >> >> for projects like Darktable.
>> >> >
>> >> > Sorry, but I fail to see how this issue is any different from
>> >> > e.g. consumers of libexiv and the resulting changes to richness
>> >> > of the EXIF
>> >>
>> >> Having an older libexiv2 will not prevent files from being read at
>> >> all. Having an old libraw could result in images being "green"
>> >> instead of properly white balanced in some cases. And in even fewer
>> >> cases it could result in files not loading at all (where they
>> >> should have just loaded just fine (and/or not being green) with
>> >> unpatched darktable sources).
>> >>
>> >> > data supported with various versions of that library: as long as
>> >> > the API is the same, newest version of the library most often is
>> >> > preferred.
>> >>
>> >> Yes, but that isn't what happens in reality. What happens in
>> >> reality is that Debian is usually behind, really...
>> >>
>> >> > If I misunderstood and there is really something more intimate
>> >> > going on specifically with Darktable and its libraries could you
>> >> > please try elaborate more on that?
>> >>
>> >> With regard to the patch, LibRaw does RAW reading _and_ processing,
>> >> we only use the RAW reading bits (which is fairly atypical). But
>> >> the LibRaw processing bits don't support float DNGs (which we use
>> >> for HDR IIRC), so the LibRaw authors are blocking them from being
>> >> read. So we need to patch that up for our particular use.
>> >>
>> >> Besides the above, there is nothing more intimate going on, except
>> >> that I see lots of potential problems, with little or no gain at
>> >> all in our particular case.
>> >
>> > Thanks for the details.
>> >
>> > It still sound to me like Darktable would make good sense to link
>> > against shared libraries for Debian.
>>
>> I don't see how you'd resolve the float issue. But even if that were
>> to be resolved. What is the perceived benefit in this particular case?
>
> Same benefits as with other cases.  This is nicely described in Debian
> Policy: http://www.debian.org/doc/debian-policy/footnotes.html#f30

1. Having multiple copies of the same code in Debian is inefficient

Ok. I get that. But it's hardly worth creating problems for.

2. often creates either static linking or shared library conflicts

I'm not sure how that would happen. Including local libraries
generally avoids that problem, instead of creating it.

3. and, most importantly, increases the difficulty of handling
security vulnerabilities in the duplicated code.

This is a good point, particularly for network/Internet facing program
and libraries.

Though for LibRaw it's a rather theoretical point. I've never seen a
report of a crafted RAW (not that it couldn't exist). And considering
the amount of code handling the different RAW formats I would be
surprised if it's not vulnerable in multiple ways already (if one were
to look). Really take a look at the LibRaw code :)

Also, taking UFRaw as an example, includes it's own internally linked
copy of dcraw.c which serves the exact same purpose for UFRaw as
LibRaw does for us. It seems odd we should get different treatment.

Regards,
Pascal de Bruijn