From: Andrew R. <and...@us...> - 2004-07-06 09:21:23
|
I've checked the debian policy on java packages ( in /usr/share/doc/java-common/policy.txt.gz ). The relevant policy on libraries is below. Looks like we should put plplot.jar in /usr/share/java as plplot-version.jar with a symlink to plplot.jar. The JNI wrapper plplotjavac_wrap.so should go in /usr/lib/jni, again presumably with a version. This may have loading implications? I don't think it is worth splitting it into two packages for the architecture dependent/independent parts. Andrew Debian java policy extract: --------------------------- 2.4 Java libraries Libraries are not separated between developers (-dev) and users versions, since this is meaningless in Java. Java libraries packages must be named libXXX[version]-java (without the brackets), where the version part is optional and should only contain the necessary part. The version part should only be used to avoid naming colisions. The XXX part is the actual package name used in the text below. Their classes must be in jar archive(s) in the directory /usr/share/java, with the name packagename[-extraname]-fullversion.jar. The extraname is optional and used internaly within the package to separate the different jars provided by the package. The fullversion is the version of that jar file. In some cases that is not the same as the package version. Some package must also provide a symbolic link from packagename-extraname.jar to the most compatible version of the available packagename-extraname-version.jar files. Java libraries must depend on the needed runtime environment (java1-runtime and/or java2-runtime) but should not depend (only suggest) java-virtual-machine. All jar files must have a well-documented CLASSPATH, so that developers should know what to add to their wrappers. This applies only to libraries, not to the core classes provied by a the runtime environment. Some Java libraries rely on code written in a "native" language, such as JNI (Java Native Interface) code. This native code is compiled into separate dynamic libraries which are loaded by the Java virtual machine at runtime. If a Java library relies on native code, the dynamic libraries containing this compiled native code should be installed into the directory /usr/lib/jni. These dynamic libraries should be shipped in a separate architecture-specific package named libXXX[version]-jni. The package containing the Java bytecode (generally libXXX[version]-java) should depend on this package. There may be situations, such as with very small packages, where it is better to bundle the Java code and the native code together into a single package. Such packages should be architecture-specific and follow the usual libXXX[version]-java naming convention. |
From: Alan W. I. <ir...@be...> - 2004-07-06 11:46:47
|
On 2004-07-06 10:21+0100 Andrew Ross wrote: > > I've checked the debian policy on java packages > ( in /usr/share/doc/java-common/policy.txt.gz ). Thanks for finding that file, Andrew. I think parts of it are also relevant to our tarball version of PLplot. Generally, I am willing to trust that Debian does the right thing about where it installs files. So I suggest that once Rafael finalizes install locations for the Debian package, that we also follow the same rules in the tarball version of PLplot. Also, Rafael, there is some good advice in that file for java packagers beyond what Andrew quoted. > > The relevant policy on libraries is below. Looks like we should put > plplot.jar in /usr/share/java as plplot-version.jar with a symlink to > plplot.jar. I agree that would conform to policy. But the quote from policy on the version is ambiguous: "In some cases that is not the same as the package version." That of course implies that in most cases it is the same as the package version. But that confuses me because clearly the package version is optional while apparently there must be a version of the jar file. Anyhow, I leave it to Rafael to figure out what that version should be for the jar file in his Debian package. (Versions are nothing but a PIA most times.) Rafael, should we avoid this issue for the tarball by not having a versioned jar file name in that case? > The JNI wrapper plplotjavac_wrap.so should go in > /usr/lib/jni, again presumably with a version. This may have loading > implications? Andrew, if you are referring to whether the shared object itself should have a version, I could find nothing in the policy about that case. My own feeling is versioning of dynamically loaded shared objects is not needed since we don't do versioning with any of our other dynamically loaded shared objects (the python shared object and our device driver shared objects) that are only dynamically loaded. libplplottcltk is versioned, but that is because it is used both as a dynamically loaded shared object and an ordinary library which is linked by some of our executables. Furthermore, if you look at the results from apt-file search /usr/lib/jni there are only 12 shared objects in total in that directory throughout Debian testing. 3 shared objects are versioned (with 3 corresponding unversioned .so files) while the remaining 6 shared objects are unversioned (end with .so rather than .so.version). So this suggests that versioning of jni shared objects is optional and although currently this is small numbers nevertheless, 6 of the 9 packages involved chose no versioning. So let's make it 7 of 10. :-) Those not interested in Debian packaging detail should skip the rest of this. :-) (But virtually everything before this is relevant to our tarball.) > I don't think it is worth splitting it into two packages for the > architecture dependent/independent parts. I agree. So according to policy such a package with both the jar file and JNI shared object in it should be named libplplot-java, where I have assumed the optional version is dropped from the package name. I don't know whether Rafael is already following this convention or not for the package name. It's way past time for me to get some sleep. Good night! Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Andrew R. <and...@us...> - 2004-07-06 09:09:07
|
Rafael, > If you are subscribed to plplot-cvs, you probably noticed that I just > committed changes to the files in debian/ that allow the generation > of a PLplot-Java package for Debian. This is just a preliminary try, > but I would like to get some feedback from the people interested in > both Java and Debian. Before all, I must confess that my interest in > Java is quite low and I am only working on this for altruism, because > our Debian users deserve the best. Thanks for putting this package together. Hopefully this will increase the profile of the plplot java bindings. I've tested and installed the package and it seems to work ok for me! > 2) Dependencies > > So far, I only tested the package building/usability using either a > combination of gcj/fastjar/gij of kaffe. I am using the following > in debian/control (only entries relevant to Java are shown): > > Source: plplot > Build-Depends: libgcj4-dev | kaffe-dev, gcj | kaffe, fastjar | > kaffe > > Package: libplplot-java > Depends: gcj | kaffe, gij | kaffe > I would gladly add alternatives to these two possibilities, so > please tell me what is appropriate. Should we be using the dummy package java-compiler to detect a java compiler. Our java usage is minimalistic enough that it should work with just about any alternative. Currently that does just seem to be gcj and jikes. Also as I understand it the kaffe package actually provides a JVM not a compiler so that is definitely wrong. For the runtime we don't need a compiler (it should possibly be a suggest?). All we need is a JVM. The dummy package java-virtual-machine should provide that. I think these are all the dependancies we need. Andrew |
From: Alan W. I. <ir...@be...> - 2004-07-06 10:06:52
|
On 2004-07-06 10:09+0100 Andrew Ross wrote: > > Rafael, > >> If you are subscribed to plplot-cvs, you probably noticed that I just >> committed changes to the files in debian/ that allow the generation >> of a PLplot-Java package for Debian. This is just a preliminary try, >> but I would like to get some feedback from the people interested in >> both Java and Debian. Before all, I must confess that my interest in >> Java is quite low and I am only working on this for altruism, because >> our Debian users deserve the best. > > Thanks for putting this package together. Hopefully this will increase > the profile of the plplot java bindings. I want to add my thanks, as well. > > I've tested and installed the package and it seems to work ok for me! Andrew's test will have to do for now because of my time constraints, but I will be happy to test it next week. > >> 2) Dependencies >> >> So far, I only tested the package building/usability using either a >> combination of gcj/fastjar/gij of kaffe. I am using the following >> in debian/control (only entries relevant to Java are shown): >> >> Source: plplot >> Build-Depends: libgcj4-dev | kaffe-dev, gcj | kaffe, fastjar | >> kaffe >> >> Package: libplplot-java >> Depends: gcj | kaffe, gij | kaffe > >> I would gladly add alternatives to these two possibilities, so >> please tell me what is appropriate. > > Should we be using the dummy package java-compiler to detect a java > compiler. Our java usage is minimalistic enough that it should work > with just about any alternative. Currently that does just seem to be > gcj and jikes. Also as I understand it the kaffe package actually > provides a JVM not a compiler so that is definitely wrong. For the > runtime we don't need a compiler (it should possibly be a suggest?). > All we need is a JVM. The dummy package java-virtual-machine should > provide that. I think these are all the dependancies we need. Thanks, Andrew for that clarification. I agree the compiler dependency should be java-compiler. Also, fastjar is required. But I assume both of those would only be build dependencies and only suggested (or is that recommended?) for the binary package. The java virtual machine (jvm or java run time) is not used during the build stage but is used for the binary package. So the binary package should depend on java-virtual-machine. The free-java-sdk package dependencies caused fastjar, sablevm, and jikes-sablevm to be installed on my system. sablevm provides java-virtual-machine, and jikes-sablevm provides java-compiler so the dependencies suggested above would work for me. Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Alan W. I. <ir...@be...> - 2004-07-06 18:12:49
|
On 2004-07-06 02:57-0700 Alan W. Irwin wrote: > On 2004-07-06 10:09+0100 Andrew Ross wrote: >> Rafael wrote: >>> I would gladly add alternatives to these two possibilities, so >>> please tell me what is appropriate. >> >> [...]For the >> runtime we don't need a compiler (it should possibly be a suggest?). >> All we need is a JVM. The dummy package java-virtual-machine should >> provide that. I think these are all the dependancies we need. > > Thanks, Andrew for that clarification. [...] > So the binary package should depend on java-virtual-machine. After writing that, I read Andrew's post referring to /usr/share/doc/java-common/policy.txt.gz which has some additional remarks about dependencies. In particular there is a run-time dependency called java-runtime which a java-virtual-machine package does not have to directly provide (although it must depend on such a package). I don't understand exactly the distinction being made between the virtual machine and runtime, but sablevm provides all of java-virtual-machine, java1-runtime, and java-runtime while gij-3.3 provides java-virtual-machine and java1-runtime. So it appears these dependencies are lumped together for now and we could depend on either java-virtual-machine or java1-runtime, but at some point the distinction between these two may become important. Andrew, what is the distinction between java virtual machine and java runtime in the traditional java world? In light of the new knowledge, which of java-virtual-machine or java1-runtime would you recommend for a dependency? Rafael, assuming that you tried make check and ./plplot-test.sh in the installed examples, it is interesting that you got plplot to work for kaffe. So that makes three free java virtual machines (and several proprietary ones) that our plplot interface works on. That indicates we have a pretty robust solution that depends only on the most common parts of the java virtual machine. However, despite getting plplot-java to work for kaffe, I would recommend completely replacing that kaffe dependency with the more generic java-virtual-machine (or java1-runtime depending on what Andrew recommends) dependency instead. The big advantage of that change is plplot-java (or all of plplot?) won't be held back from debian-testing promotion by that kaffe dependency. From http://bjorn.haxx.se/debian/testing.pl?package=kaffe there are a number of build problems for kaffe and also at least one release critical bug, and as a consequence it apparently has never made it into testing (or else it was removed). Those are all bad signs at this late date in the release cycle. In contrast to the kaffe problems on Debian, according to http://bjorn.haxx.se/debian/testing.pl?package=sablevm, sablevm has its latest version in testing, and according to http://bjorn.haxx.se/debian/testing.pl?package=gij-3.3, the latest gij version is too young to go into testing today, but it looks like it will go in tomorrow without any problems. Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Rafael L. <rla...@us...> - 2004-07-06 20:13:15
|
* Alan W. Irwin <ir...@be...> [2004-07-06 11:04]: > After writing that, I read Andrew's post referring to > /usr/share/doc/java-common/policy.txt.gz which has some additional remarks > about dependencies. In particular there is a run-time dependency called > java-runtime which a java-virtual-machine package does not have to directly > provide (although it must depend on such a package). I don't understand > exactly the distinction being made between the virtual machine and runtime, > but sablevm provides all of java-virtual-machine, java1-runtime, and > java-runtime while gij-3.3 provides java-virtual-machine and java1-runtime. > So it appears these dependencies are lumped together for now and we could > depend on either java-virtual-machine or java1-runtime, but at some point > the distinction between these two may become important. For a terse explanation of virtual packages, look at the file /usr/share/doc/debian-policy/virtual-package-names-list.txt.gz, in the debian-policy package. > Rafael, assuming that you tried make check and ./plplot-test.sh in the > installed examples, it is interesting that you got plplot to work for kaffe. Yes, it did. > However, despite getting plplot-java to work for kaffe, I would recommend > completely replacing that kaffe dependency with the more generic > java-virtual-machine (or java1-runtime depending on what Andrew recommends) > dependency instead. The big advantage of that change is plplot-java (or all > of plplot?) won't be held back from debian-testing promotion by that kaffe > dependency. Well, if I use : Package: libplplot9-java Depends: java-virtual-machine | kaffe Recommends: java-compiler | kaffe then the PLplot packages won't be stuck in unstable. > From http://bjorn.haxx.se/debian/testing.pl?package=kaffe there > are a number of build problems for kaffe and also at least one release > critical bug, I built kaffe smoothly in my Debian testing system. > and as a consequence it apparently has never made it into testing (or else > it was removed). It was removed. > Those are all bad signs at this late date in the release cycle. The only critical release bug filled against kaffe is tagged "pending", so the situation is not that bad (see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=257173) -- Rafael |
From: Alan W. I. <ir...@be...> - 2004-07-06 20:53:15
|
On 2004-07-06 22:12+0200 Rafael Laboissiere wrote: > For a terse explanation of virtual packages, look at the file > /usr/share/doc/debian-policy/virtual-package-names-list.txt.gz, in the > debian-policy package. To be explicit, that file says the following virtual package names have been approved for java-related use: Java and virtual machines ------------------------- java-compiler a java compiler, for Java version 1 java2-compiler a java compiler, for Java version 2 java-virtual-machine a JAVA virtual machine java1-runtime a Java runtime environment, Java version 1 java2-runtime a Java runtime environment, Java version 2 So we have the choice of java-virtual-machine or java1-runtime depending on which Andrew thinks is the best. > Well, if I use : > > Package: libplplot9-java > Depends: java-virtual-machine | kaffe > Recommends: java-compiler | kaffe > > then the PLplot packages won't be stuck in unstable. Good point. Another question (that I cannot answer since I don't have access to Debian unstable) is whether kaffe provides both java-virtual-machine and java1-runtime? If so, you could drop it from the Depends regardless of what Andrew decides is best of either java-virtual-machine or java1-runtime. Also, as far as I can tell, java-compiler refers to the ability to compile java source into java byte code, i.e., the *.class files. This should not be confused with the ability some jvm's have to compile the byte code into native code in a JIT (just-in-time) manner. According to the description, kaffe does have JIT capability, but works with byte-compiled files as input so I believe it is incorrect to OR it with java-compiler in the Recommends. Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Alan W. I. <ir...@be...> - 2004-07-06 21:32:43
|
On 2004-07-06 13:53-0700 Alan W. Irwin wrote: > Also, as far as I can tell, java-compiler refers to the ability to compile > java source into java byte code, i.e., the *.class files. This should not > be confused with the ability some jvm's have to compile the byte code into > native code in a JIT (just-in-time) manner. According to the description, > kaffe does have JIT capability, but works with byte-compiled files as input > so I believe it is incorrect to OR it with java-compiler in the Recommends. Now I am really confused since Rafael discovered a javac (which is used to byte-compile *.java files into *.class files) buried in kaffe, and from the description it also has a java (run-time) capability. So it sounds like kaffe provides the java-compiler, java-virtual-machine, and java runtime capabilities all rolled into one. Rafael, does it state all those capabilites clearly with the appropriate virtual package names? If not, maybe it is time to post a java policy violation bug report against kaffe? Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Rafael L. <rla...@us...> - 2004-07-06 22:11:11
|
* Alan W. Irwin <ir...@be...> [2004-07-06 14:32]: > On 2004-07-06 13:53-0700 Alan W. Irwin wrote: > > >Also, as far as I can tell, java-compiler refers to the ability to compile > >java source into java byte code, i.e., the *.class files. This should not > >be confused with the ability some jvm's have to compile the byte code into > >native code in a JIT (just-in-time) manner. According to the description, > >kaffe does have JIT capability, but works with byte-compiled files as input > >so I believe it is incorrect to OR it with java-compiler in the Recommends. > > Now I am really confused since Rafael discovered a javac (which is used to > byte-compile *.java files into *.class files) buried in kaffe, and from the > description it also has a java (run-time) capability. So it sounds like > kaffe provides the java-compiler, java-virtual-machine, and java runtime > capabilities all rolled into one. Rafael, does it state all those > capabilites clearly with the appropriate virtual package names? As I wrote in a previous post, the kaffe package does not provide any virtual package, even in unstable: # apt-cache show kaffe | grep -v "^" Package: kaffe Priority: optional Section: interpreters Installed-Size: 112 Maintainer: Ean R. Schuessler <ea...@no...> Architecture: all Version: 2:1.1.4.PRE1.1.5-7 Depends: kaffe-pthreads | kaffe-jthreads Filename: pool/main/k/kaffe/kaffe_1.1.4.PRE1.1.5-7_all.deb Size: 49300 MD5sum: 6bfedb90da8854411646b607257601bd Description: A JVM to run Java bytecode > If not, maybe it is time to post a java policy violation bug report against > kaffe? Maybe. -- Rafael |
From: Rafael L. <rla...@us...> - 2004-07-06 20:29:00
|
* Andrew Ross <and...@us...> [2004-07-06 10:09]: * Alan W. Irwin <ir...@be...> [2004-07-06 02:57]: > On 2004-07-06 10:09+0100 Andrew Ross wrote: > > > Should we be using the dummy package java-compiler to detect a java > > compiler. Our java usage is minimalistic enough that it should work with > > just about any alternative. Currently that does just seem to be gcj and > > jikes. Also as I understand it the kaffe package actually provides a JVM > > not a compiler so that is definitely wrong. The kaffe package does provide a compiler: $ dpkg -L kaffe | grep javac /usr/lib/kaffe/bin/javac It is too bad that the kaffe package does not provide any virtual package. > > For the runtime we don't need a compiler (it should possibly be a > > suggest?). All we need is a JVM. The dummy package java-virtual-machine > > should provide that. I think these are all the dependancies we need. > > Thanks, Andrew for that clarification. I agree the compiler dependency > should be java-compiler. Also, fastjar is required. But I assume both of > those would only be build dependencies and only suggested (or is that > recommended?) for the binary package. The java virtual machine (jvm or java > run time) is not used during the build stage but is used for the binary > package. So the binary package should depend on java-virtual-machine. > > The free-java-sdk package dependencies caused fastjar, sablevm, and > jikes-sablevm to be installed on my system. > > sablevm provides java-virtual-machine, and jikes-sablevm provides > java-compiler so the dependencies suggested above would work for me. What must be a dependency and what can be a recommendation/suggestion? The Depends relationship must be used only when a dependent package is unusable without the depending one. Users installing libplplot-java in their systems would fall in two categories: in the first one, Java programmers who will write their own programs and "link" against plplot.jar; they would need java-compiler and java-virtual-machine. In the second category, there would be users who will only use Java programs written by others. They would only need java-virtual-machines. Do you think that the following would be appropriate: Package: libplplot-java Depends: java-virtual-machine Recommends: java-compiler (Actually, I would have "java-virtual-machine | kaffe" and "java-compiler | kaffe", for those users having kaffe installed in their systems.) * Alan W. Irwin <ir...@be...> [2004-07-06 04:37]: > On 2004-07-06 10:21+0100 Andrew Ross wrote: > > > > >I've checked the debian policy on java packages > >( in /usr/share/doc/java-common/policy.txt.gz ). > > Thanks for finding that file, Andrew. I think parts of it are also relevant > to our tarball version of PLplot. Generally, I am willing to trust that > Debian does the right thing about where it installs files. So I suggest that > once Rafael finalizes install locations for the Debian package, that we also > follow the same rules in the tarball version of PLplot. It would be better to do it the other way around, otherwise I will have to revert changes in m y Debian package later, doing useless work. The plplot.jar file is currently installed in ${prefix}/share/plplot5.3.1.cvs/java/. Do anyone object if we change this now to ${prefix}/share/java/? > >The relevant policy on libraries is below. Looks like we should put > >plplot.jar in /usr/share/java as plplot-version.jar with a symlink to > >plplot.jar. > > I agree that would conform to policy. But the quote from policy on the > version is ambiguous: "In some cases that is not the same as the package > version." That of course implies that in most cases it is the same as the > package version. But that confuses me because clearly the package version > is optional while apparently there must be a version of the jar file. > Anyhow, I leave it to Rafael to figure out what that version should be > for the jar file in his Debian package. (Versions are nothing but a PIA > most times.) > > Rafael, should we avoid this issue for the tarball by not having a versioned > jar file name in that case? Theoretically, the version of the jar file should be independent of the version of PLplot, like the SOVERSION for the shared libraries. This means that we could maintain a separate JARVERSION variable in cf/java.ac or in configure.ac. This variable should be updated only when the Java API effectively changes. However, if the other developers consider this to be a PITA, I do not care doing the other way. > I agree. So according to policy such a package with both the jar file and > JNI shared object in it should be named libplplot-java, where I have assumed > the optional version is dropped from the package name. I don't know whether > Rafael is already following this convention or not for the package name. I decided that I will call the PLplot Java package libplplot<version>-java, where <version> is the major part of SOVERSION (we will have eventually libplplot9-java). The reason for that is related to the upgrading of Debian packages. For that reason, I am already have versioned names for the driver packages, plplot9-driver-xwin, plplot9-driver-gd, etc. -- Rafael |
From: Alan W. I. <ir...@be...> - 2004-07-06 21:25:15
|
On 2004-07-06 22:28+0200 Rafael Laboissiere wrote: > Do you think that the following would be > appropriate: > > Package: libplplot-java > Depends: java-virtual-machine > Recommends: java-compiler That might work depending on what Andrew thinks is best and what virtual package names kaffe supplies. See my last post on this for further discussion. > [...]The > plplot.jar file is currently installed in > ${prefix}/share/plplot5.3.1.cvs/java/. Do anyone object if we change this > now to ${prefix}/share/java/? Fine with me. > Theoretically, the version of the jar file should be independent of the > version of PLplot, like the SOVERSION for the shared libraries. This means > that we could maintain a separate JARVERSION variable in cf/java.ac or in > configure.ac. This variable should be updated only when the Java API > effectively changes. However, if the other developers consider this to be a > PITA, I do not care doing the other way. I don't care either for the tarball version of PLplot as long as you are willing to maintain JARVERSION. :-) > I decided that I will call the PLplot Java package libplplot<version>-java, > where <version> is the major part of SOVERSION (we will have eventually > libplplot9-java). The reason for that is related to the upgrading of Debian > packages. For that reason, I am already have versioned names for the > driver packages, plplot9-driver-xwin, plplot9-driver-gd, etc. On this issue it is your convenience (as Debian packager) that is at stake so whatever you think is best. Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Rafael L. <rla...@us...> - 2004-07-06 22:07:13
|
* Alan W. Irwin <ir...@be...> [2004-07-06 14:25]: > On 2004-07-06 22:28+0200 Rafael Laboissiere wrote: > > That might work depending on what Andrew thinks is best and what virtual > package names kaffe supplies. See my last post on this for further > discussion. > > >[...]The > >plplot.jar file is currently installed in > >${prefix}/share/plplot5.3.1.cvs/java/. Do anyone object if we change this > >now to ${prefix}/share/java/? > > Fine with me. If others do not object, could you please make the appropriate changes to the relevant Makefile.am? > >Theoretically, the version of the jar file should be independent of the > >version of PLplot, like the SOVERSION for the shared libraries. This means > >that we could maintain a separate JARVERSION variable in cf/java.ac or in > >configure.ac. This variable should be updated only when the Java API > >effectively changes. However, if the other developers consider this to be > >a > >PITA, I do not care doing the other way. > > I don't care either for the tarball version of PLplot as long as you are > willing to maintain JARVERSION. :-) I noticed the smile but, jokes apart, I am not the appropriate person for maintaining JARVERSION. This variable should be maintained by someone who is actively maintaining what goes into the plplot.jar file. You? Andrew? -- Rafael |