Fails to build with metadata-extractor 2.10.1

[sebastic]

As reported by Markus Koschany in Debian Bug #866762:

I would like to update libmetadata-extractor-java in sid to the latest
version. This is needed to complete the update of pdfsam.
Unfortunately the update will break gpsprune. The new package is
already available in experimental. I am attaching an incomplete patch
that fixes most of the errors caused by renamed methods but the
hasThumbnail and hasThumbnailData methods no longer exist. This issue
is known upstream as

drewnoakes/metadata-extractor#149

Maybe they will be reintroduced in a later version but perhaps the
author of gpsprune might want to change this anyway. Please get in
touch with him.

metadata-extractor-2.10.1.patch

[activityworkshop]

Thanks for letting me know about this.
If I understand that other issue correctly, the library has lost its ability to read thumbnail images out of jpegs, is that right? And it might possibly be added again at some time in the future?

In that case, if GpsPrune has to be compatible with version 2.10 (which I assume it must), then GpsPrune must also lose its ability to read the thumbnail images, which is a shame.

Would it make sense for me to provide a GpsPrune 18.7 with just this little patch in it (or you could even patch it yourself, taking out the thumbnail section too)? This would provide a quick fix to let you get things into unstable. Or alternatively the patch could become part of GpsPrune 19, but that may take a little while longer to finish the testing. Which would you prefer?

[sebastic]

The issue speaks of TIFF images, for which other classes exist to read the thumbnail.

It does look like metadata-extractor chose to break its API again without caring about its wider userbase, as it's infamous for.

For the Debian package I'll apply Markus' patch and comment out the hasThumbnail call in ExternalExifLibrary.java if the changes to deal with latest metadata-extractor version are not available in a new GpsPrune release yet when the new libmetadata-extractor-java package is updated in unstable.

[activityworkshop]

I asked the libmetadata-extractor project for help with this, and it looks like with version 2.10 it's really not going to be possible without writing (duplicating) additional code to re-parse the exif data blobs after the libmetadata-extractor has finished. And that doesn't seem the right way to do it.

Rewind to when gpsprune was introduced to Debian, and it was dapal who persuaded me to add this dependency rather than just integrate the relevant bits of the code into the GpsPrune.jar. But for non-Debian users, I didn't want to add this extra dependency, so GpsPrune has since come in two versions, with an "internal" or an "external" Exif-handling capability.

I'm not sure who would be able to decide whether GpsPrune could now be "allowed" to include its internal Exif-handling capability in Debian, but I feel that that would be the best solution to this problem. All you'd have to do is remove the "_debian" from the source filename. I think that would be the best way to avoid losing the thumbnail-reading abilities.

[sebastic]

While using embedded copy copies is greatly discouraged, the Debian package for JOSM has switched to using the embedded copy of metadata-extractor too, because the transitions it triggers are so unpleasant and it allows for much easier backports of JOSM for Debian stable releases.

Adding another package that embeds metadata-extractor is far from great, but makes our lives much easier. I think we can be a bit more lenient on this point once more.

[sebastic]

I noticed that the regular source tarball also doesn't have the files in the tim/prune/function/srtm/gen/ directory. We still need that for the Debian package builds.

If you can switch the _debian source tarballs to use the internal exif library in future releases, that's probably sufficient.

[activityworkshop]

I'd say that this issue can be closed with the release of version 19 of GpsPrune.
It would be great if you could remove both the build-dependency and the runtime-dependency on metadata-extractor, as I don't know how to do that.
Thanks a lot!

[sebastic]

Yes, this issue can be closed.

gpsprune (19-1) has been uploaded to Debian unstable.

The metadata-extractor related changes can be found in the git repository for the package:

https://salsa.debian.org/debian-gis-team/gpsprune/commit/0105b1489818fc359b8174f4c1a8dab620c6beb9