#530 request copylib exception for dcraw.c
Closed: Fixed None by mattdm. Opened 3 years ago by mattdm.

dcraw is a standalone utility for processing RAW-format photographs and is packaged in Fedora as such. However, it ''also'' serves as a copylib in many (most? all?) higher-level open source RAW software, including RawTherapee and Darktable (via LibRaw). These versions are often tightly-coupled to the individual software, and often modified specifically. IOW, I think it's pretty squarely in the "copylib" definition.

Upstream is https://www.cybercom.net/~dcoffin/dcraw/, and note

  • "Why don't you implement dcraw as a library?" in FAQ
  • upstream distributed as .c file only

I'd like to request a "bundled(dcraw)" exception, so that this can be tracked.


It's over ten thousand lines of code (well, code+comments) which parses data from potentially unsafe sources. Having that be a copylib seems to me to be a really, really bad idea.

Replying to [comment:1 tibbs]:

It's over ten thousand lines of code (well, code+comments) which parses data from potentially unsafe sources. Having that be a copylib seems to me to be a really, really bad idea.

Well, it's not ''my'' idea. :)

There is a project called LibRaw which is basically an attempt to library-ify dcraw, but it's not quite complete and not at all a drop-in replacement. See this [https://code.google.com/p/rawtherapee/issues/detail?id=594 RawTherapee ticket] about switching to it (including discussion of the copylib issue).

Meanwhile, we do have a number of packages in Fedora including it (rawstudio and ufraw in addition to the above) and it seems better to document it. Is it possible to say

"Packagers should include Provides: bundled(dcraw), and should engage upstream about replacing this copylib with LibRaw"

or something similar?

LibRaw ''itself'' would presumably need to keep the exception permanently.

Certainly it should be documented, but that's quite a ways from saying it's OK by providing a bundling exception. Since the stuff is already in the distro and FPC doesn't have the ability to pull packages due to bundling issues (or for any other issue, for that matter), it's kind of academic (though we can theoretically stop additional bundling from entering the distro). If someone is looking for some official ruling of what to do to document this, I'll happily make one now:

Packages which bundle dcraw should add Provides: bundled(dcraw). If it is possible to determine the version of dcraw which is being bundled, packages should instead add Provides: bundled(dcraw) = version.

I personally would probably go with a bundling exception just for libraw, assuming we don't simply consider it a fork. But the other stuff, probably not.

And just as an aside, this kind of thing represents why we should be very afraid:

"Library code is ugly because it cannot use global variables." - dcraw upstream

Replying to [comment:3 tibbs]:

Certainly it should be documented, but that's quite a ways from saying it's OK by providing a bundling exception. Since the stuff is already in the distro and FPC doesn't have the ability to pull packages

Documenting what's already in is definitely my main priority, but this is fairly widespread, and it's incredibly likely that Hot New Photography Software of 2016 will do the same thing. And, unfortunately, since it really isn't meant to be a library, unbundling it isn't just packaging differently — it's a fairly invasive and extensive rewrite to the software to use an alternative.

I'm not saying you're wrong, just that it's the state of the software.

Packages which bundle dcraw should add Provides: bundled(dcraw). If it is possible to determine the version of dcraw which is being bundled, packages should instead add Provides: bundled(dcraw) = version.

FWIW, "version" is usually going to be "version + patches". The file does carry a revision number (it is, apparently, managed with RCS upstream), which could reasonably be considered to be the version.

Added Provides: bundled(dcraw) = 9.25 to LibRaw in rawhide per 2015-05-14 FPC meeting.

We discussed this at this weeks meeting (http://meetbot.fedoraproject.org/fedora-meeting-1/2015-05-14/fpc.2015-05-14-16.01.txt):

  • 530 request copylib exception for dcraw.c (geppetto, 16:06:58)

  • LINK: https://fedorahosted.org/fpc/ticket/530 (geppetto, 16:06:59)
  • ACTION: Everything using it should add a bundled(dcraw), until it's
    a true fork. (geppetto, 16:21:50)
  • ACTION: It's way too big and messy to be classified as a copylib
    though, any potential users should probably look at moving to libraw
    (geppetto, 16:22:25)

Rather than "isn't classified as a copylib", I'd phrase it as "it's a copylib, but a terrible one and we can't grant a bulk exception". :) But anyway, thanks for looking at it.

According to upstream, it isn't a copylib. It's intended to be a command line application only. Upstream does not recommend that the source be added to any other program.

In this review request (1) doesn't consider dcraw as bundle when have an exact copy (1)
I don't understand how we bundle things that aren't libraries (3) [[br]]
May I reopen this ? , looks to me after 7 months nobody unbundle dcraw

(1) https://bugzilla.redhat.com/show_bug.cgi?id=569204

(2) https://bugzilla.redhat.com/show_bug.cgi?id=569204#c9

rawtherapee-3.0/rtengine/dcraw.c: Exact copy from dcraw (dcraw/dcraw.c)

(3) https://bugzilla.redhat.com/show_bug.cgi?id=1248730#c4

FPC is no longer involved in bundling policy (and according to the policy FESCo has written, there's no requirement to unbundle anything), so there is no point in having an open FPC ticket related to this.

Metadata Update from @sergiomb:
- Issue assigned to tibbs

2 years ago

Login to comment on this ticket.

Metadata