Bug 385717 – updated ebuild for sci-geosciences/josm

• Status: RESOLVED FIXED
• Product: Gentoo Linux

[Description Dmytro Gorbunov 2011-10-05 10:43:23 UTC]

Created attachment 288843 [details]
updated ebuild for josm

Hello,

I've updated ebuild for josm to the latest stable revision ( 4487 ) as stated in the official site http://josm.openstreetmap.de/

Also I did another 2 things
- remove downloading precompiled versions of the app from http://josm.fabian-fingerle.de/
  (I don't really understand why it was there)

- remove unset SUBVERSION_ECLASS - it looks like a strange hack

With kind regards,
Dmytro Gorbunov

P.S. It's my first submitted ebuild so please forgive me if I did something completely wrong (and provide the explanation please)


diff:

diff josm-4487.ebuild /usr/portage/sci-geosciences/josm/josm-4203.ebuild
9,15c9,10
< SUBVERSION_ECLASS="subversion"
< if [[ ${PV} == "9999" ]]; then
<       ESVN_REPO_URI="http://josm.openstreetmap.de/svn/trunk"
< else
<       ESVN_REPO_URI="http://josm.openstreetmap.de/svn/trunk@4487"
< fi
< 
---
> [[ ${PV} == "9999" ]] && SUBVERSION_ECLASS="subversion"
> ESVN_REPO_URI="http://josm.openstreetmap.de/svn/trunk"
16a12
> unset SUBVERSION_ECLASS
18a15,16
> HOMEPAGE="http://josm.openstreetmap.de/"
> [[ ${PV} == "9999" ]] || SRC_URI="http://josm.fabian-fingerle.de/${P}.tar.xz"
31a30
>       if [[ ${PV} == "9999" ]]; then
41a41
>       fi

[Comment 1 Vincent de Phily 2011-12-15 23:36:57 UTC]

(comming here from bug #391773)

A variation of this patch works for me. My patch is different because I wanted to keep using a tarball for the stable release (this is usefull because downloading is faster, and having subversion installed *shouldn't* be necessary).

But using the tarball, I still hit the snag that it contains an svn 1.7 metadata directory, and the build tool tries to use that to create a revision file. Since the svn metadata changed between 1.6 and 1.7, it means you need subversion 1.7 installed to be able to build from the tarball.

To add more sillyness, the build.xml file in the tarball already contains the svn revision number, making the whole overhead pointless (if the packager generates a "build.xml" with the needed info, he could generate a "revision.xml" right there and stop wasting bandwidth by packaging the svn folders). Ultimately, this is an upstream packager bug. I'll try to get in touch with them.

I tried patching the build system via the ebuild so that no revision-wizardry is done, but this gets annoyingly complicated (ant/java are not my friends either). So I think that the simplest fix is to depend on subversion >= 1.7 for the stable ebuild.

Ironically, the live ebuild works fine with and old subversion client, since the svn server is backward-compatible.


--- josm-4550.ebuild    2011-11-24 11:30:13.438756303 +0100
+++ josm-4608.ebuild    2011-12-16 00:12:12.311545220 +0100
@@ -6,18 +6,21 @@
 
 JAVA_ANT_ENCODING=UTF-8
 
-[[ ${PV} == "9999" ]] && SUBVERSION_ECLASS="subversion"
-ESVN_REPO_URI="http://josm.openstreetmap.de/svn/trunk"
-inherit eutils java-pkg-2 java-ant-2 ${SUBVERSION_ECLASS}
-unset SUBVERSION_ECLASS
+inherit eutils java-pkg-2 java-ant-2
+if [[ ${PV} == "9999" ]]; then
+       inherit subversion
+       ESVN_REPO_URI="http://josm.openstreetmap.de/svn/trunk"
+       KEYWORDS="~amd64 ~x86"
+else
+       SRC_URI="http://josm.fabian-fingerle.de/${P}.tar.xz"
+       KEYWORDS="amd64 x86"
+fi
+
 
 DESCRIPTION="Java-based editor for the OpenStreetMap project"
 HOMEPAGE="http://josm.openstreetmap.de/"
-[[ ${PV} == "9999" ]] || SRC_URI="http://josm.fabian-fingerle.de/${P}.tar.xz"
-
 LICENSE="GPL-2"
 SLOT="0"
-[[ ${PV} == "9999" ]] || KEYWORDS="~amd64 ~x86"
 
 DEPEND=">=virtual/jdk-1.6"
 RDEPEND=">=virtual/jre-1.6"

[Comment 2 Marcel Pennewiß 2012-02-06 23:56:05 UTC]

Could you try to use the new packed tar.xz from http://opensource.pennewiss.de/josm/

I wrote a bash script which repacks the svn-repository without svn-dependency. I'm not a Java-coder but this repack works for me. If it works i'll also provide newer versions...

[Comment 3 Marcel Pennewiß 2012-02-06 23:56:58 UTC]

(In reply to comment #0)
> - remove unset SUBVERSION_ECLASS - it looks like a strange hack

cleaning unused vars is not a strange hack ;) it was me...

[Comment 4 Florian Manschwetus 2012-05-28 19:48:18 UTC]

as upstream doesn't maintain a src-release and this is a pure java application is there any reason for not just installing the class-files provided by upstream as jar-file?

[Comment 5 Florian Manschwetus 2012-05-28 19:49:05 UTC]

(In reply to comment #4)
> as upstream doesn't maintain a src-release and this is a pure java
> application is there any reason for not just installing the class-files
> provided by upstream as jar-file?

Especially as this matter renders this package useless currently

[Comment 6 Hanno Böck 2013-01-13 12:30:55 UTC]

I've now committed an updated package that doesn't depend on svn any more.
@Marcel Pennewiß, this is partly through your ideas, thanks. However, I thought it'd be better if I host and patch this stuff on my own.
@Florian Manschwetus: We had jar-packages in the past, but gentoo policy is to use source-packages when the source is available. Anyway, this is not the place to discuss gentoo policy and I'll try to stick with it as it is.