Got the deb from the OBS:
Error: darktable depends on libexiv2-27 (>= 0.27.5-1.1)
After some digging I found that no debian provides a newer version than 0.27.3.
The exiv2 website is not helpful either. No non-dev-people instructions provided.
Can someone provide clear instructions?
(Ansible playbook preferred.)
Install at least version 27.5
D’oh. 
But how? No apt/dpkg deb for debian, not even on OBS, pure nothing.
Instructions unclear.
PS: That version is only a few weeks old, why is it not packaged with darktable, since it is a hard requirement?
hello!
libexiv2-27 version 0.27.5 is included in the OBS repo.
i’d suggest you to follow the commands on the OBS page for darktable, it should resolve the dependecies automatically. don’t just get the .deb, but add the repo:
https://software.opensuse.org/download.html?project=graphics:darktable&package=darktable
edit: libexiv 0.27.5 is in the OBS repo: https://software.opensuse.org/package/libexiv2-27
Because that’s not how a shared library system works. You only need the newer version if you need cr3 support.
Because it is not a hard requirement.
Seems build failed for *ubuntu distros.
Can you please tell that to dpkg on debian10? 
Maybe there is a mistake how OBS builds the deb-package, but the end-result is: darktable 3.8.0-1.1 will not be installed until libexiv2-27 (>= 0.27.5-1.1) is present. And as a user I do not have the time and nerves to dig into and understand the build+dependency process of yet another library.
This is exactly why I don’t run Debian/Ubuntu anymore 
Seems your experience is as old as the habit to bash “the others”.
Apple iOS is probably more UNIX than Ubuntu is debian.
Please tell me about that magic silver bullet operating system that is perfect.
And how to install that nextgen libexiv stuff that hasn’t even made it into debian sid testing, which is a very clear sign that it is overly cutting edge. Which would make it perfect for the ArchLinux realm, but I do need to run servers with stability, so I left that one behind a long time ago.
Looks more like a packaging problem rather than a problem with debian dependencies management no?
Not really, I was a Debian user for like 20 years. I just got tired of building deb packages. I didn’t bash you, I wanted more control over my software stack, so I moved to a distro that gave me the tooling to do so.
Who cares? That has nothing to do with this.
Absolutely not what I said. Sorry someone shit in your cereal this morning, but don’t misinterpret my words.
Well if you bought a cutting edge canon camera, this is what you need in order to support cr3. It would have been great I’d they just kept on with cr2, which is well supported, but here we are.
I don’t know, but if you know, please help.
I’m not into datktable but that is maybe something to check at the linker step?
Just guessing, i’m not going to debug that now.
On a side note, please don’t feel personnaly offenfed every time someone is asking or suggesting something.
Where did I do this?
Often enough for many to notice
Then please PM the moderators and use the quote function of the forum to highlight this behavior. Or use the flag button that is available on every post.
I’ve looked at the build logs for Ubuntu 20.04 the other day and the errors seem to be triggered by lintian (which i assume is a “linter” for Debian packages.
I have close to zero experience with Linux packaging (I managed to build a lensfun deb package once, but I can’t say I completely understood what I was doing).
Most of what Lintian complains about are just warnings, but the first two are marked as errors (and likely causing the build to fail).
Both errors seem to b related to files that are included in debian.tar.xz, but I have no idea how/where to download it.
[ 540s] + lintian -i /usr/src/packages/exiv2_0.27.5-1.1_amd64.changes
[ 577s] E: exiv2 changes: bad-distribution-in-changes-file unstable
[ 577s] N:
[ 577s] N: You've specified an unknown target distribution for your upload in the
[ 577s] N: debian/changelog file. It is possible that you are uploading for a
[ 577s] N: different distribution than the one Lintian is checking for. In that
[ 577s] N: case, passing --profile $VENDOR may fix this warning.
[ 577s] N:
[ 577s] N: Note that the distributions non-free and contrib are no longer valid.
[ 577s] N: You'll have to use distribution unstable and Section: non-free/xxx or
[ 577s] N: Section: contrib/xxx instead.
[ 577s] N:
[ 577s] N: Refer to Debian Policy Manual section 5.6.14 (Distribution) for details.
[ 577s] N:
[ 577s] N: Severity: error
[ 577s] N:
[ 577s] N: Check: changes-file
[ 577s] N:
[ 577s] E: libexiv2-27: symbols-file-contains-current-version-with-debian-revision on symbol _ZN5Exiv210BasicErrorIcEC1IA14_cA5_cEENS_9ErrorCodeERKT_RKT0_@Base and 48 others
[ 577s] N:
[ 577s] N: Debian revisions should be stripped from versions in symbols files. Not
[ 577s] N: doing so leads to dependencies unsatisfiable by backports (1.0-1~bpo <<
[ 577s] N: 1.0-1 while 1.0-1~bpo >= 1.0). If the Debian revision can't be stripped
[ 577s] N: because the symbol really appeared between two specific Debian
[ 577s] N: revisions, you should postfix the version with a single "~" (example:
[ 577s] N: 1.0-3~ if the symbol appeared in 1.0-3).
[ 577s] N:
[ 577s] N: This problem normally means that the symbols were added automatically by
[ 577s] N: dpkg-gensymbols. dpkg-gensymbols uses the full version number for the
[ 577s] N: dependency associated to any new symbol that it detects. The maintainer
[ 577s] N: must update the debian/<package>.symbols file by adding the new symbols
[ 577s] N: with the corresponding upstream version.
[ 577s] N:
[ 577s] N: Severity: error
[ 577s] N:
[ 577s] N: Check: shared-libs
//EDIT:
the version/ build ID should probably also be incremented to 0.27.5-2 to distinguish it from the -1 build that didn’t have ISOBMFF support.
Oh, come on, you can do better than this, @paperdigits …
And don’t drag out a conversation by just throwing around empty content posts - not a single of your answers had anything to offer to solve my initial and ongoing problem. I know software development is hard and even harder doing it properly but standing on a soap box does never help. No hard feelings, I just like my conversations and debugging straight to point.
Current status from a user perspective: sloppy release management.
Of course the devs doing the hard work here have all their dependencies and ducks in a row, know the ins and outs where to pull what, how to make the cake and so on. But having to dig through a foreign code-base and it’s unresolved dependencies is really hard for an outsider.
So … anyone (else) can show me how to get libexiv up and running?