On Sat, Jul 28, 2012 at 6:19 PM, Jonas Smedegaard d...@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 d...@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 d...@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
