best Depends: line for an app that needs Java 5 but prefers Java 6?
Hi. I maintain various GPL programs that aren't in Debian, but which
are available as .deb packages from http://software.jessies.org/ and
I was wondering if anyone here had any good ideas about our Depends:
lines.
Looking for a solution to my perceived problem (which I'll get to in
a moment), I came across the following on this list, which led me to
believe this would be a good place to hear pertinent opinions:
Marcus Better wrote:
> Benjamin Mesing wrote:
> > I want to build a package which requires Java 5. Therefore I
> > build-depend on (sun-java5-jdk | sun-java6-jdk).
>
> Please don't do this, just select one of them.
I see Marcus' point, but I think that's a very difficult choice.
My problem, as I see it, is that my packages' "true dependency" is on
sun-java5-jdk. The only other working alternative is sun-java6-jdk.
Simple, you say: claim to depend on sun-java5-jdk and all is well.
(Strictly sun-java[56]-jre, but that's another can of worms that I'm
happy to ignore for now. Really it's the same problem again; we can
cope with a JRE, but prefer a JDK. And, no, this isn't just because I
haven't heard of Build-Depends: ;-) .)
The problem is that, although we'll work with Java 5, but
automatically disable various features that we could offer if Java 6
were available. Plus Java 6 makes a huge difference on Linux because
the GTK+ LAF is *much* more convincing. Simple, you say: claim to
depend on sun-java6-jdk and all is well.
The trouble with that is that I'm then excluding users who don't have
sun-java6-jdk available but who would have sun-java5-jdk. If
someone's stuck on an old Debian/Ubuntu release, there's probably a
reason, and it's not my place to say "upgrade to Debian 4 or Ubuntu
7.04".
What I'd like to say is "this package depends on sun-java6-jdk, but
if there's no such package, we'll accept sun-java5-jdk". As far as
I've been able to determine, though, I can't express that. If someone
here knows how to say that, if they could enlighten me, I'll go away
a happy man.
I have read the Debian policy, and the Debian Java policy, but I
haven't found the information I need.
At the moment, my work-around is to not specify *any* JVM dependency.
At run-time, my applications check whether the first "java" on the
path is acceptable, if not falling back to checking the known
locations (in order of preference) of where a good JVM would be.
There are two disadvantages to this. One is that, by subverting the
dependencies system, we can install something non-functional, leaving
the user to manually install packages to fix the problem. (We explain
the problem, but it would obviously be preferable to just not let
such a situation arise.) The second problem is that if the user
already has sun-java5-jdk installed but has sun-java6-jdk available
in a repository, we don't cause that to be installed, even though it
would be beneficial. (We could pop up a dialog in this instance also,
but that sounds fraught with "I see you're trying to write a letter,
so now I'm going to get in your way..." difficulty.)
(I'm happy to impose the installation of *some* properly-released JVM
package on the survivalist types getting by with an OpenJDK build or
a Java 7 weekly; they're probably Java developers, and they should
probably have the JVM their users will be on, if only for testing
purposes.)
I feel like I've used too many words to get across what should
probably be a short and simple question, but I wanted to at least
give the impression that we've thought about the various choices
available to us, or at least those we know of. I've been excited for
some time at the prospect of having Sun's JVMs available as
dependencies, but now I'm confused as to how to make any use of that.
Apologies for my loquaciousness, and thanks in advance for any
suggestions you have.
--elliott
P.S. if anyone knows, I'd be curious to learn why the packages are
called sun-java5-jdk and sun-java6-jdk rather than just being
versions 5.* and 6.* of sun-java-jdk. I have the suspicion that
understanding that would be educational.
Reply to: