Re: JOSM backports and its negative effect on other packages
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
Reply to: