Re: 'debian' version for libclojure-java?
Markus Koschany <apo@debian.org> writes:
> 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.
You are correct. I made a *recent* edit (not uploaded) to change
to 1.8.0 simply to demonstate that I could indeed push to
the official repo (using git+ssh) from my alioth guest account.
I have just reverted this change.
>> 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.
Thank you for the clarification.
>> 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.
Okay.
>> 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 like that idea! Are there suggestions on how to maintain
the same source package, but have two targets in changelog,
(and the two different pristine-tar's) e.g.... ?
1. libclojure-java (1.8.0-3) unstable; urgency=low
2. libclojure-java (1.9.0~alpha17-1) experiemental; urgency=low
>> 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.
Great. Let us know where the documentation will land and how
others can help!
>> 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.
Very helpful clarification.
> 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.
Great!
Regards,
--Tom
Reply to: