Replace py3exiv2 by gexiv2

[jcjgraf]

This PR replaces the python package py3exiv2 by package gexiv2. This is done since py3exiv2 has quite a few issues/disadvantages:

• Since python10 the package does not works for me due to some version conflict
  • ImportError: libboost_python310.so.1.76.0: cannot open shared object file: No such file or directory
  • It is possible that it is due to an error on my side and easily fixable, but I did not figure out how
• py3exiv2 does not get updated and upstream does not respond
  • 8 months ago exiv2 added support for a bunch of new image formats
  • Back then, I informed upstream py3exiv2 about this updates and told them that a single new line needs to be added to the py3exiv2 codebase to enable these formats
  • I have never heard back from them and since then I maintain my own fork of py3exiv2

Besides that, we have the already known issues mentioned in e.g. #214

• only in AUR
• required many build dependencies

From the developers of exiv2 I learned about gexiv2 as an adequate replacement to py3exiv2.

Advantages/Disadvantages gexiv2:

• + Seems to provide everything py3exiv2 provides
• + The code in metadata handler gets simplified to using some convenience function
• + Is backed by GNOME and therefore in the official Arch repo (and possibly also repos of other distributions)
• + gets more regularly updated and maintainer is also active in exiv2 community
• - Installation is a bit more involved (compared to pip install py3exiv2)
  • requires the following packages on arch (and possible some more I forgot about...): python-gobject, libgexiv2
• - Overhead due to GObject?

This PR is meant as a proof-of-concept and to raise a discussion concerning py3exiv2.

I did not yet manage to install gexiv2 in the venv using tox. So it is required to be installed system-wide, and then .venv needs to be regenerated to integrate system packages.

[karlch]

Thanks for taking another look into this! I fully agree with your points raised converniny py3exiv2. It is also a complete mess to try to get the CI running with py3exiv2 for newer python versions (c.f. the ci-py39-310 branches for the havoc 😅).

However, I am not convinved that gexiv2 is the appropriate solution, mainly due to two points:

• As you describe, it is not simple to integrate into a python environment due to the required system integration, and the python-gobject based interfaced. This messes with CI (again) and is non-trivial to build (as well).
• Vaving a large gnome related dependency actually feels pretty weird, given that we use Qt here (rant: why does Qt not offer a nice exiv interface? 😞 ).

This is quite a frustrating topic, as there are so many packages out there, but none of them seem to do what we want ... In the end, maybe we end up shipping our own (wrapper) with vimiv? I have no idea how involved this would be, but at this point it may be worth looking into this (when there is more time at hand). In any case, this exiv library chaos is certainly something that should be solved before thinking about v1.0.

[jcjgraf]

I agree which everything you said. I am closing this in favour of #467