Project

General

Profile

Feature #10582

Fedora's Darktable will use Rawspeed as static library

Added by Germano Massullo over 2 years ago. Updated over 2 years ago.

Status:
Closed: won't fix
Priority:
Low
Assignee:
-
Category:
Buildsystem
Start date:
07/09/2015
Due date:
% Done:

0%

Affected Version:
git stable branch
System:
Fedora/RHEL
bitness:
64-bit
hardware architecture:
amd64/x86

Description

Hi, I am the Fedora's Darktable package co-mantainer.
The Fedora Packaging Committee, according to [1] said [2] that I must remove Rawspeed from Darktable, create a Rawspeed static library and use it in Darktable compilation.
I opened this ticket to let you know about that and keep track of important variants on Fedora from upstream Darktable version, so if anybody opens a bugreport you will be aware of this change.

[1] https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Copylibs
[2] https://fedorahosted.org/fpc/ticket/550#comment:3

History

#1 Updated by Roman Lebedev over 2 years ago

  • Subject changed from Fedora Packaging Committee to Fedora's Darktable will use Rawspeed as static library

#2 Updated by Pascal de Bruijn over 2 years ago

This seriously should NOT happen!

Darktable's camera support a tightly tied to a specific version of RawSpeed. And our copy of RawSpeed is usually ahead of upstream. Linking Darktable to an external version of RawSpeed will likely degrade, and as a consequently waste our time in having to deal with weird bugs and camera support issues.

If this issue is forced by Fedora upstream, I suggest to drop Darktable ENTIRELY from Fedora repos, and maintain an external Darktable repository with a proper version of Darktable.

#3 Updated by Pedro Côrte-Real over 2 years ago

I don't even know how you could implement this. rawspeed is not versioned so you'd end up having to just do a darktable-rawspeed package with the same version number of darktable (since we are effectively the rawspeed upstream repo here), and once you're doing that you might as well just put everything in darktable and be done with it.

The only other alternative I can see is to effectively create your own fork of rawspeed with proper versioning and patch your darktable build to request a specific version of it. That's not an insignificant effort and only really makes sense if something else would use the same version of rawspeed.

Unbundling pugixml could perhaps make sense and is something we could consider doing ourselves. At least that seems to be properly packaged by at least debian and ubuntu.

#4 Updated by Germano Massullo over 2 years ago

Rathann, member of the Fedora Packaging Committee, asked me to paste in this ticket (because he does not have a Darktable.org Redmine account) the message he sent to Klaus Post here: https://github.com/klauspost/rawspeed/issues/109#issuecomment-120377125

=====================
Hello, I'm a member of the Fedora Packaging Committee. Could you please answer our standard set of questions: https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Standard_questions ? Please also read the beginning of that page for some arguments against bundling.

Would you consider making a shared library with regular formal releases? This would make packager's life a lot easier, even if there are API/ABI breaks (just please take care of bumping the version properly). Also, nobody is asking you to support older releases (though it would be nice), that is the job of distribution package maintainers.

According to comments in http://redmine.darktable.org/issues/10582 , darktable bundles an active fork of rawspeed. Are you aware of their fork? What is your relation to the darktable project? =====================

Klaus already answered at comment https://github.com/klauspost/rawspeed/issues/109#issuecomment-120386991

#5 Updated by Pascal de Bruijn over 2 years ago

The problem is that there should be no shared library ever. This is NOT a good idea at all.

Camera support is a application specific thing. NOT a distribution specific thing. Wanting to share this between between several applications is an incredibly stupid thing to want.

#6 Updated by Pascal de Bruijn over 2 years ago

PS: I do agree with pedrocr that externalising pugixml will probably be fine though.

#7 Updated by Pascal de Bruijn over 2 years ago

Germano, please do note I'm not annoyed at you. I'm aware you're trying to guide this process along. I am however very annoyed at how Fedora is handling this.

#8 Updated by Germano Massullo over 2 years ago

Pascal de Bruijn wrote:

Germano, please do note I'm not annoyed at you. I'm aware you're trying to guide this process along. I am however very annoyed at how Fedora is handling this.

There is no problem Pascal :-)
Rathann (Dominik) started a discussion in Fedora Packaging list, so if you are interested in the whole discussion that just started https://lists.fedoraproject.org/pipermail/packaging/2015-July/010813.html
In particular I appreciated the reply of Matthew Miller, the Fedora Project Leader: https://lists.fedoraproject.org/pipermail/packaging/2015-July/010821.html

#9 Updated by Germano Massullo over 2 years ago

Discussion is going on here with partecipation also of some Darktable developers
https://github.com/klauspost/rawspeed/issues/109#issuecomment-120668893

#10 Updated by Pascal de Bruijn over 2 years ago

@Miller, that is indeed encouraging, and in my opinion the right approach :)

#11 Updated by Pedro Côrte-Real over 2 years ago

  • Status changed from New to Closed: won't fix
  • Tracker changed from Bug to Feature

Hopefully this issue is dead at least until Fedora decides to bikeshed once more. :)

Also available in: Atom PDF