Hey Tom, Am 14.08.2017 um 20:24 schrieb Tom Marble: > > All: > > I found that in creating a Java package that depends on Clojure [0] > I had to patch to a specific version [1].
I'm a bit confused here. When we worked on this package, didn't we change the version to 1.8.x instead of 1.8.0 ? The former is correct because new package versions like 1.8.1, 1.8.2, etc. won't break your reverse-dependencies every time you package a new version of libclojure-java then. A strict dependency on a specific version is rarely needed. Only some Maven plugins come to my mind right now. > I'm wondering if it would be better to depend on 'clojure' > (or 'libclojure-java') as unversioned? Better depend on libclojure-java because clojure will pull in the JDK and that is not desired for library packages. You can use an unversioned build-dependency whenever it is certain that it won't break any reverse-dependencies (that's the default case). Only when you notice that some packages will FTBFS with a newer version of a certain library and you have to make adjustments in those packages, it makes sense to tighten the version of this specific build-dependency. > There *is* a case where Debian developers may want to have > the next (as yet unreleased) version of Clojure (1.9.0-alpha17) > in the archive to begin working with with clojure.spec (among other features). > With some luck we can fix upstream to build/run on OpenJDK 9. > > In the former case it seems like we should have the current > package declare a 'debian' version (which it does not now): > > tmarble@cerise 109 :) dpkg -L libclojure-java | grep 'pom$' > /usr/share/maven-repo/org/clojure/clojure/1.8.0/clojure-1.8.0.pom > /usr/share/maven-repo/org/clojure/clojure/1.8.x/clojure-1.8.x.pom > tmarble@cerise 110 :) > > ACTION: Is it OK if we add a 'debian' version to this package? I believe the current version of 1.8.x is wrong and it should be changed to "debian". The debian version is the default one anyway and you won't even need a maven.rule in reverse-dependencies like shimdandy anymore. > For the latter case should we create a new, versioned package > like 'clojure-snapshot' ('libclojure-snapshot-java') or some such? It makes sense to create a new package like libclojure-snapshot-java in this case. You can also upload new snapshot versions of clojure to experimental if you don't require those version for anything being in unstable. In this case you could avoid some work and you wouldn't have to create a new source package. > I have the impression that our policy around these issues > is not accurately documented and up-to-date? Is that correct > -or- am I missing a secret "new" Debian Java Policy packaging > guide for maven helper?? I am not sure. I believe using the "debian" version is the preferred way for all Java packages. You only have to diverge from this naming scheme in case of packages which are known to break reverse-dependencies like ASM in the past (or more recently libpdfbox-java) when we had to package multiple ASM packages with different versions. > Debian Java Policy [3] (as linked from [4]) is silent on mvn versioning? > There is some discussion of the 'debian' version on [5]. Debian Java Policy is in most cases still relevant but other parts need a clarification or update. My goal is to provide a better documentation for packaging Java software for Debian first (documenting best practice) and then I intend to discuss further Policy changes on this list, if needed. > Can someone remind me why we have both maven-repo-helper [6] and > maven-debian-helper [7]? Is maven-debian-helper going to be our > tool of choice? maven-debian-helper is definitely our recommended tool of choice if you want to package Java software that uses the Maven build system. maven-repo-helper is basically our tool to provide support for Maven when there is no support in a package itself. So for instance you would use maven-repo-helper together with an Ant based package if it is important to you that jar files are also installed into /usr/share/maven-repo but if you have a pure Maven package, just use maven-debian-helper. IMO it would be great if we could merge both tools in the future. I'm not totally sure why previous team members decided to provide two different but quite similar tools. If so are there plans to, you know, improve > the quality of mh_make? Yes, that would be great too. I guess there are a lot of wishlist bugs by now. AFAIK nobody is working on an update at the moment but the goal should be to make mh_make more robust to produce a working debian directory or at least give advice how to proceed. > Please advise, > > --Tom Regards, Markus
signature.asc
Description: OpenPGP digital signature