Description of problem: darktable2 is a replacement for darktable EPEL7 package that ships 1.x darktable releases. darktable upstream developers develop only 2.x releases. To be compliant to EPEL packaging guidelines, I am making a new package for 2.x releases. Since darktable 2 once it reads darktable 1.x XML files will make them uncompatible with older 1.x releases, I inserted a Obsoletes: darktable flag. If you see build errors concerning pugixml version, don't worry about it because there is a new version that is going to be released https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-dce60c46e0 spec file: https://germano.fedorapeople.org/package_reviews/darktable2_epel7/darktable2.spec srpm file: https://germano.fedorapeople.org/package_reviews/darktable2_epel7/darktable2-2.0.6-1.fc24.src.rpm
There should not be problems in the spec file since it has already been reviewed when darktable 2 landed into Fedora repositories https://bugzilla.redhat.com/show_bug.cgi?id=1281478
Downgrading to 2.0.5 due upstream request (Nikon support broken in 2.0.6) https://fedorapeople.org/~germano/package_reviews/darktable2_epel7/darktable2.spec https://fedorapeople.org/~germano/package_reviews/darktable2_epel7/darktable2-2.0.5-1.fc24.src.rpm
to get rid of the .gitignore file we just need to add the second rm: # Remove bundled lua rm -rf src/external/lua/ # Remove .gitignore file rm -f data/lua/darktable/external/pygy_require/.gitignore The other Errors are rpath errors and can be ignored for now. However for a later build we should see if we can remove the rpath link in the binaries and add a file in /etc//ld.so.conf.d/ like the one below. $ cat darktable-x86_64.conf /usr/lib64/darktable/
https://fedorapeople.org/~germano/package_reviews/darktable2_epel7/darktable2.spec https://fedorapeople.org/~germano/package_reviews/darktable2_epel7/darktable2-2.0.5-1.fc24.src.rpm (In reply to Oliver Haessler from comment #3) > However for a > later build we should see if we can remove the rpath link in the binaries > and add a file in /etc//ld.so.conf.d/ like the one below. > > $ cat darktable-x86_64.conf > /usr/lib64/darktable/ Could you explain in detail the problem? I would like to patch the Fedora's darktable too. Thank you
Wouldn't it make sense to just update the existing darktable package to 2.0? I am not sure it's worth keeping around both 1.x and 2.x, it's just confusing users.
(In reply to Kalev Lember from comment #5) > Wouldn't it make sense to just update the existing darktable package to 2.0? > I am not sure it's worth keeping around both 1.x and 2.x, it's just > confusing users. https://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#Some_examples_of_what_package_updates_that_are_fine_or_not
I think this applies mostly to libraries in order to keep ABI/API stable in EPEL. I don't think the policy is meant to keep leaf desktop apps on old, unsupported versions forever.
(In reply to Germano Massullo from comment #4) > https://fedorapeople.org/~germano/package_reviews/darktable2_epel7/ > darktable2.spec > https://fedorapeople.org/~germano/package_reviews/darktable2_epel7/ > darktable2-2.0.5-1.fc24.src.rpm > > (In reply to Oliver Haessler from comment #3) > > However for a > > later build we should see if we can remove the rpath link in the binaries > > and add a file in /etc//ld.so.conf.d/ like the one below. > > > > $ cat darktable-x86_64.conf > > /usr/lib64/darktable/ > > Could you explain in detail the problem? I would like to patch the Fedora's > darktable too. > Thank you The feedback was based on https://fedoraproject.org/wiki/Packaging:Guidelines#Beware_of_Rpath
After asking in EPEL development mailing list I decided to insert darktable 2.x into darktable EPEL7 branch[1], because: - 1.x is no longer upstream maintained; - there are no API/ABI that can be broken; - it is a desktop application. Oliver, thank you for your time. I will take care of your suggestions in main darktable tree [1]. [1]: https://admin.fedoraproject.org/pkgdb/package/rpms/darktable/