JOSM backports and its negative effect on other packages
Now that we finally have a new JOSM tested snapshot in Debian, we need
to decide whether or not to maintain backports for it too. This was
requests about two years ago in #705548, and the experience with the
outdated JOSM 8159 in Debian for some time (popular plugins require more
recent tested snapshots) show that there is a need for recent JOSM
versions for stable users.
Backporting JOSM also required backporting JMapViewer. The jmapviewer
package in Debian is also a dependency on freeplane which tends to break
with JMapViewer releases.
JOSM also frequently requires more recent metadata-extractor releases,
and these updates tend to break the other libmetadata-extractor-java
reverse dependencies too (gpsprune & tika).
libmetadata-extractor-java, freeplane & tika are maintained by the Java
team, and they, like me, may not want to deal with these breakages in
stable too.
The josm (0.0.svn8800+dfsg3-1) package, that is expected to migrate to
testing soon, was changed to use the embedded copies of JCS and
metadata-extractor as this was the only way to get a new JOSM build in
Debian. This makes maintaining a backport much easier, because it
doesn't pull in newer metadata-extractor versions to break gpsprune &
freeplane, and allows us to build JOSM in Debian without having JCS
packaging available (as is also the case for javax.json).
Since we generally don't want embedded copies in Debian, the use of
these in JOSM should be a temporary thing until the requirements are met
by the packages. We'll then need backports for the various packages from
the Java team too, I don't want to ask this of them just to enable JOSM
backports, nor do I want to maintain those backports too (although that
seems the most feasible option).
I'm not entirely happy with the embedded copies in JOSM, because I
consider it an admission of defeat that Debian is unable to keep up with
fast moving Java projects like that. But it does make maintenance of the
package easier, with much less need to coordinate updates to prevent
breakage.
To summarize, I'd like to maintain backports for josm and its extended
family (jmapviewer, josm-plugins & openstreetmap-map-icons), but I don't
want to require backports for the packages maintained by the Java team.
The current suboptimal situation for JOSM 8800 makes that an option, but
not entirely up to Debian standards.
Should we worry about breaking freeplane with the jmapviewer updates? Or
tika if go for libmetadata-extractor-java backports?
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Reply to: