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
Attachment:
signature.asc
Description: OpenPGP digital signature