On 10/21/2015 12:23 AM, Sebastiaan Couwenberg wrote: > 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?
I've bit the bullet, and backported josm. The openstreetmap-map-icons, jmapviewer, josm & josm-plugin packages were accepted into jessie-backports today. Hopefully no freeplane users also want the josm backport, because they cannot have both. Felix indicated that backporting freeplane and its related packages was a lot of work, so that's unlikely to happen. freeplane users are advised to use the upstream JOSM tested jar if they need a newer JOSM on jessie instead of installing the backport. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
