Re: Packaging a library, with JNI and javadocs
Hi On Thu, Sep 12, 2002 at 04:32:34PM +1000, Ben Burton wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > > > Well the -java name extension should only (have I written that in policy?) > > be used for arch-independent packages. I would recommend an -jni name > > extension instead. > > Hmm.. I packaged libreadline-java (a small JNI library with a couple of > wrapper classes) with the -java extension as a result of (my understanding > of) the java policy. :) Well. It is mostly because to help the build daemons. Many java packages (especially in the contrib section) depend on non-packaged stuff to build the package. So arch independent -java packages are really nice. > Is there a particular reason to distinguish between native Java classes and > classes with JNI implementations? As far as whoever's using them is > concerned, they appear the same, no? I know to little about jni to answer this. > The only issue I could think of was that you want the JVM to find the JNI > library in its default search path; I resolved this by putting the > corresponding C library in /usr/lib, and this appears to work fine from what > testing I've done. If you have suggestions on how this should be done I really look forward for this kind of stuff. As I said: I do not know very much about JNI... :( > > > Now, I've packaged a few simple programs before but never Java. Are > > > there any small packages out there which use JNI I could look at for > > > examples? > > Well, I can offer libreadline-java for you to look at, but that of course > doesn't mean it's done the Right Way. :) I have now taken a _quick_ look at it. Would it be possible to use the .c stuff (arch dependent) stuff outside of java? Can the java classes be used without the .c (arch dependent) stuff? It can be used in main so non-free things is not an issue. I know I'm in favour of splitting things but I also know that all people are not. :) Regards, // Ola > Ben. :) > > - -- > > Ben Burton > [EMAIL PROTECTED] | [EMAIL PROTECTED] > Public Key: finger [EMAIL PROTECTED] > > I don't hide much, but sometimes people don't understand that I > talk about them. Then we sit in the same room and they haven't got a clue. > That's also the reason why I don't want to explain every detail of my work. > - Tori Amos, Haaggsche Courant, 1994 > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.0.7 (GNU/Linux) > > iD8DBQE9gDUFMQNuxza4YcERAveyAJwIoRRtUWWua+Ez5Hq2w9Z8HonJfACghY+f > hhXMy4/UrZrg/Xm9HInh7jQ= > =wBI7 > -END PGP SIGNATURE- > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > -- - Ola Lundqvist --- / [EMAIL PROTECTED] Annebergsslingan 37 \ | [EMAIL PROTECTED] 654 65 KARLSTAD | | +46 (0)54-10 14 30 +46 (0)70-332 1551 | | http://www.opal.dhs.org UIN/icq: 4912500 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / --- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packaging a library, with JNI and javadocs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > Well. It is mostly because to help the build daemons. Many java packages > (especially in the contrib section) depend on non-packaged stuff to build > the package. So arch independent -java packages are really nice. I'm not sure I see how this helps the build daemons. If something depends on non-packaged stuff at build time, the build daemons can't build it anyway since they won't have the build dependencies available to them. If something doesn't depend on non-packaged stuff at build time then the build daemons should be fine regardless of architecture. > I have now taken a _quick_ look at it. Would it be possible to use the > .c stuff (arch dependent) stuff outside of java? Not really. The C library contains java-specific wrappers. In fact, all that's really in the libreadline-java C library is java-specific wrappers to the usual libedit routines. > Can the java classes be used without the .c (arch dependent) stuff? No. They will not function without the C library (the JVM will throw an exception if the C library is not available). > I know I'm in favour of splitting things but I also know that all people > are not. :) I do believe in this instance that neither the java classes nor the C library make sense without the other. Ben. :) - -- Ben Burton [EMAIL PROTECTED] | [EMAIL PROTECTED] Public Key: finger [EMAIL PROTECTED] To love oneself is the beginning of a lifelong romance. - Oscar Wilde -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9gJKjMQNuxza4YcERAoq5AJ9pV9P8GLKNQx4iChrj4cC2XcQ9aQCgmpFe p6haJIjTU/7MV1CyK0vcgcY= =gCmJ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packaging a library, with JNI and javadocs
Appropriate timing for me. I was planning on packaging portions of OCF, which will include some JNI libraries. On Thu, 2002-09-12 at 09:12, Ben Burton wrote: > > Well. It is mostly because to help the build daemons. Many java packages > > (especially in the contrib section) depend on non-packaged stuff to build > > the package. So arch independent -java packages are really nice. > > I'm not sure I see how this helps the build daemons. If something depends on > non-packaged stuff at build time, the build daemons can't build it anyway > since they won't have the build dependencies available to them. If something > doesn't depend on non-packaged stuff at build time then the build daemons > should be fine regardless of architecture. I'm in favor of using the -java for JNI + supporting java classes. After all, it's still a Java library - it's just architecture dependant. Instead of using -jni, I vote the package be built architecture dependant. eg. as opposed to _all.deb it's a _i386.deb. > > I have now taken a _quick_ look at it. Would it be possible to use the > > .c stuff (arch dependent) stuff outside of java? > > Not really. The C library contains java-specific wrappers. In fact, all > that's really in the libreadline-java C library is java-specific wrappers to > the usual libedit routines. > > > Can the java classes be used without the .c (arch dependent) stuff? > > No. They will not function without the C library (the JVM will throw an > exception if the C library is not available). They cannot be used but can be built. > > I know I'm in favour of splitting things but I also know that all people > > are not. :) > > I do believe in this instance that neither the java classes nor the C library > make sense without the other. In my particular case, the java source and the JNI source come from two upstreams. I was planning to separate the debian packages like so: - arch-dependant JNI libraries go into libocf-pcsc and similar, recommending (or depending on - I'll accept suggestions) libocf-pcsc-java (or similar). - arch-independant java classes will go into libocf-pcsc-java and similar, depending on libocf-pcsc. If the Java and JNI sources come from the same upstream, I think it still makes sense to keep the packages together, just making an architecture dependant package. Or you can go my route and separate them. IMHO, using -jni seems redundant. Either way though, I'll follow common convention or Policy where possible. -joe -- Innovation Software Group, LLC - http://www.innovationsw.com/ Business Automation Specialists UNIX, Linux and Java Training -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packaging a library, with JNI and javadocs
On Thu, Sep 12, 2002 at 10:00:03AM -0400, Joe Phillips wrote: > I'm in favor of using the -java for JNI + supporting java classes. > After all, it's still a Java library - it's just architecture > dependant. Instead of using -jni, I vote the package be built > architecture dependant. eg. as opposed to _all.deb it's a _i386.deb. I second this. It should be put in the Java policy this way. There has been a discussion about native-compiled Java code using gcj on this list some month ago but no consensus was reached. Maybe this could be resolved together with the JNI matter now? Greetings, Stefan Gybas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packaging a library, with JNI and javadocs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > I'm in favor of using the -java for JNI + supporting java classes. FWIW, I support this also. But to go into more detail: > - arch-dependant JNI libraries go into libocf-pcsc and similar, > recommending (or depending on - I'll accept suggestions) > libocf-pcsc-java (or similar). In this case however I might argue for something clear in the arch-dependant package name that it's a JNI library, eg., libocf-pcsc-jni instead of just libocf-pcsc. The main reason being that (I presume) the C library provides java-specific functions and so there seems little reason to use it outside the context of JNI. So I guess my stance is then to either: - - use a single package named libfoo-java with both the java classes and the C library, or: - - use two packages, these being libfoo-java containing the java classes and libfoo-jni containing the C library. I don't see any particular need to favour only one of these options as policy; I can see circumstances where each option (splitting vs not splitting) has its benefits. Ben. - -- Ben Burton [EMAIL PROTECTED] | [EMAIL PROTECTED] Public Key: finger [EMAIL PROTECTED] A cigarette is the perfect type of a perfect pleasure. It is exquisite, and it leaves one unsatisfied. What more can one want? - Oscar Wilde -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9gKY+MQNuxza4YcERAieIAJ9tkfFPaRC3Bf5eXY3ixFhAIgvkFACgiFpi YrMikfzP4kcqwilABtpxoIg= =hjxN -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packaging a library, with JNI and javadocs
On Thu, 2002-09-12 at 10:35, Ben Burton wrote: > So I guess my stance is then to either: > - - use a single package named libfoo-java with both the java classes and the C > library, or: > - - use two packages, these being libfoo-java containing the java classes and > libfoo-jni containing the C library. > > I don't see any particular need to favour only one of these options as policy; > I can see circumstances where each option (splitting vs not splitting) has > its benefits. Your suggestions seem reasonable to me. -joe -- Innovation Software Group, LLC - http://www.innovationsw.com/ Business Automation Specialists UNIX, Linux and Java Training -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packaging a library, with JNI and javadocs
On Thu, Sep 12, 2002 at 04:15:13PM +0200, Stefan Gybas wrote: > On Thu, Sep 12, 2002 at 10:00:03AM -0400, Joe Phillips wrote: > > > I'm in favor of using the -java for JNI + supporting java classes. > > After all, it's still a Java library - it's just architecture > > dependant. Instead of using -jni, I vote the package be built > > architecture dependant. eg. as opposed to _all.deb it's a _i386.deb. > > I second this. It should be put in the Java policy this way. > > There has been a discussion about native-compiled Java code using > gcj on this list some month ago but no consensus was reached. Maybe > this could be resolved together with the JNI matter now? They seem very similar so yes it should be resolved. :) Regards. // Ola > Greetings, > Stefan Gybas > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > -- - Ola Lundqvist --- / [EMAIL PROTECTED] Annebergsslingan 37 \ | [EMAIL PROTECTED] 654 65 KARLSTAD | | +46 (0)54-10 14 30 +46 (0)70-332 1551 | | http://www.opal.dhs.org UIN/icq: 4912500 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / --- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packaging a library, with JNI and javadocs
Hi On Fri, Sep 13, 2002 at 12:35:42AM +1000, Ben Burton wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > > > I'm in favor of using the -java for JNI + supporting java classes. > > FWIW, I support this also. But to go into more detail: I'd like to extend this some. > > - arch-dependant JNI libraries go into libocf-pcsc and similar, > > recommending (or depending on - I'll accept suggestions) > > libocf-pcsc-java (or similar). > > In this case however I might argue for something clear in the arch-dependant > package name that it's a JNI library, eg., libocf-pcsc-jni instead of just > libocf-pcsc. I second this. I also suggest that gcj files go to a package named -gjc. But I also think that the policy should say 'should' and explain that it in some situations (if the packages are small and have few dependencies) it might be better to have just one package. > The main reason being that (I presume) the C library provides java-specific > functions and so there seems little reason to use it outside the context of > JNI. > > So I guess my stance is then to either: > - - use a single package named libfoo-java with both the java classes and the C > library, or: > - - use two packages, these being libfoo-java containing the java classes and > libfoo-jni containing the C library. And I say that the default thing should be the second one (with addition for -gcj) unless the package is very small and have very little extra in its dependencies. Is there something called dependency file size? > I don't see any particular need to favour only one of these options as policy; > I can see circumstances where each option (splitting vs not splitting) has > its benefits. Agreed. It should be mentioned in the policy. Regards, // Ola > Ben. > > - -- > > Ben Burton > [EMAIL PROTECTED] | [EMAIL PROTECTED] > Public Key: finger [EMAIL PROTECTED] > > A cigarette is the perfect type of a perfect pleasure. It is exquisite, > and it leaves one unsatisfied. What more can one want? > - Oscar Wilde > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.0.7 (GNU/Linux) > > iD8DBQE9gKY+MQNuxza4YcERAieIAJ9tkfFPaRC3Bf5eXY3ixFhAIgvkFACgiFpi > YrMikfzP4kcqwilABtpxoIg= > =hjxN > -END PGP SIGNATURE- > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > -- - Ola Lundqvist --- / [EMAIL PROTECTED] Annebergsslingan 37 \ | [EMAIL PROTECTED] 654 65 KARLSTAD | | +46 (0)54-10 14 30 +46 (0)70-332 1551 | | http://www.opal.dhs.org UIN/icq: 4912500 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / --- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packaging a library, with JNI and javadocs
On Thu, Sep 12, 2002 at 11:12:00PM +1000, Ben Burton wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > > > Well. It is mostly because to help the build daemons. Many java packages > > (especially in the contrib section) depend on non-packaged stuff to build > > the package. So arch independent -java packages are really nice. > > I'm not sure I see how this helps the build daemons. If something depends on > non-packaged stuff at build time, the build daemons can't build it anyway > since they won't have the build dependencies available to them. If something > doesn't depend on non-packaged stuff at build time then the build daemons > should be fine regardless of architecture. It was recently a discussion on debian-policy about this. They was discussing build-arch vs build-indep. So no right now it is not really useful but maybe in a short time. > > I have now taken a _quick_ look at it. Would it be possible to use the > > .c stuff (arch dependent) stuff outside of java? > > Not really. The C library contains java-specific wrappers. In fact, all > that's really in the libreadline-java C library is java-specific wrappers to > the usual libedit routines. > > > Can the java classes be used without the .c (arch dependent) stuff? > > No. They will not function without the C library (the JVM will throw an > exception if the C library is not available). Ok. I'm thinking that maybe -java shoud be for "true" java and then use -jni for everything that is not "true" java. > > I know I'm in favour of splitting things but I also know that all people > > are not. :) > > I do believe in this instance that neither the java classes nor the C library > make sense without the other. Now I'm more convinced of using -jni as extension. Yes I know I'm changing constantly ;) Regards, // Ola > Ben. :) > > - -- > > Ben Burton > [EMAIL PROTECTED] | [EMAIL PROTECTED] > Public Key: finger [EMAIL PROTECTED] > > To love oneself is the beginning of a lifelong romance. > - Oscar Wilde > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.0.7 (GNU/Linux) > > iD8DBQE9gJKjMQNuxza4YcERAoq5AJ9pV9P8GLKNQx4iChrj4cC2XcQ9aQCgmpFe > p6haJIjTU/7MV1CyK0vcgcY= > =gCmJ > -END PGP SIGNATURE- > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > -- - Ola Lundqvist --- / [EMAIL PROTECTED] Annebergsslingan 37 \ | [EMAIL PROTECTED] 654 65 KARLSTAD | | +46 (0)54-10 14 30 +46 (0)70-332 1551 | | http://www.opal.dhs.org UIN/icq: 4912500 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / --- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packaging a library, with JNI and javadocs
Hi again. I have a new (very similar to the last one) that should go into the policy. JNI, gcj and other architecture dependend versions of java: JNI libraries consist of something that is architecture dependent and possibly(?) architecture independent java classes. These should go into a packages called libfoo-jni for the architecture dependent files. Java classes and other architecture independent stuff can/should be split into libfoo-java package if some/all of it can be used without the architecture dependent files. When gcj libraries is compiled from java source, these architecture dependent library files should go into an architecture dependent package called libfoo-gcj. Architecture independent java classes should/must be split into a corresponding libfoo-java package. Is this something that can go into policy (yes clarifications can be in place so please comment it)? I assume that it is more to say about jni and gcj but this is at least a start. :) Regards, // Ola On Thu, Sep 12, 2002 at 06:14:45PM +0200, Ola Lundqvist wrote: > > FWIW, I support this also. But to go into more detail: > > I'd like to extend this some. > > > > - arch-dependant JNI libraries go into libocf-pcsc and similar, > > > recommending (or depending on - I'll accept suggestions) > > > libocf-pcsc-java (or similar). > > > > In this case however I might argue for something clear in the arch-dependant > > package name that it's a JNI library, eg., libocf-pcsc-jni instead of just > > libocf-pcsc. > > I second this. > > I also suggest that gcj files go to a package named -gjc. But I also think > that the policy should say 'should' and explain that it in some situations > (if the packages are small and have few dependencies) it might be better > to have just one package. > > > The main reason being that (I presume) the C library provides java-specific > > functions and so there seems little reason to use it outside the context of > > JNI. > > > > So I guess my stance is then to either: > > - - use a single package named libfoo-java with both the java classes and the C > > library, or: > > - - use two packages, these being libfoo-java containing the java classes and > > libfoo-jni containing the C library. > > And I say that the default thing should be the second one (with addition for > -gcj) unless the package is very small and have very little extra in its > dependencies. Is there something called dependency file size? > > > I don't see any particular need to favour only one of these options as policy; > > I can see circumstances where each option (splitting vs not splitting) has > > its benefits. > > Agreed. It should be mentioned in the policy. > > Regards, > > // Ola > > > Ben. > > > > - -- > > > > Ben Burton > > [EMAIL PROTECTED] | [EMAIL PROTECTED] > > Public Key: finger [EMAIL PROTECTED] > > > > A cigarette is the perfect type of a perfect pleasure. It is exquisite, > > and it leaves one unsatisfied. What more can one want? > > - Oscar Wilde > > > > -BEGIN PGP SIGNATURE- > > Version: GnuPG v1.0.7 (GNU/Linux) > > > > iD8DBQE9gKY+MQNuxza4YcERAieIAJ9tkfFPaRC3Bf5eXY3ixFhAIgvkFACgiFpi > > YrMikfzP4kcqwilABtpxoIg= > > =hjxN > > -END PGP SIGNATURE- > > > > > > -- > > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > > > -- > - Ola Lundqvist --- > / [EMAIL PROTECTED] Annebergsslingan 37 \ > | [EMAIL PROTECTED] 654 65 KARLSTAD | > | +46 (0)54-10 14 30 +46 (0)70-332 1551 | > | http://www.opal.dhs.org UIN/icq: 4912500 | > \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / > --- > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > -- - Ola Lundqvist --- / [EMAIL PROTECTED] Annebergsslingan 37 \ | [EMAIL PROTECTED] 654 65 KARLSTAD | | +46 (0)54-10 14 30 +46 (0)70-332 1551 | | http://www.opal.dhs.org UIN/icq: 4912500 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / --- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packaging a library, with JNI and javadocs
On Thu, 2002-09-12 at 17:20, Ola Lundqvist wrote: > Now I'm more convinced of using -jni as extension. Yes I know I'm changing > constantly ;) As I started this thread, I suppose I best say something. I am also in favour of the pure approach -- pure Java libraries in libfoo-java, which depends on architecture dependant libraries in libfoo-jni. Ross -- Ross Burton mail: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] www: http://www.burtonini.com./ PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF signature.asc Description: This is a digitally signed message part
Re: Packaging a library, with JNI and javadocs
Ola Lundqvist <[EMAIL PROTECTED]> writes: > Ok. I'm thinking that maybe -java shoud be for "true" java and then > use -jni for everything that is not "true" java. FWIW, perl libraries are currently packaged as ...-perl regardless of whether they include (arch dependent) shared objects or only perl code. Actually of the packages ending their name in '-perl', 335 are arch:all, and 142 are not. -- Robbe signature.ng Description: PGP signature
Re: Packaging a library, with JNI and javadocs
W liście z czw, 12-09-2002, godz. 20:17, Robert Bihlmeyer pisze: > Ola Lundqvist <[EMAIL PROTECTED]> writes: > > > Ok. I'm thinking that maybe -java shoud be for "true" java and then > > use -jni for everything that is not "true" java. > > FWIW, perl libraries are currently packaged as ...-perl regardless of > whether they include (arch dependent) shared objects or only perl > code. Actually of the packages ending their name in '-perl', 335 are > arch:all, and 142 are not. I'd like to say my opinion. I think that using -java suffix is OK as long, as the code is such package can be used by every standard JVM/classlib. So it seems doubful if we need -jni suffix if such code can be run by every ordinary JVM (but I would not be against such suffix if the others want to go this way). However as gcj-compiled programs are no longer java (IMO) - it woulnd't harm if we delegate separate -gcj suffix for such packages. Regards Grzegorz B. Prokopski -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packaging a library, with JNI and javadocs
The problem here is that a package that includes jni and Java code probably can't be auto-built on all architectures, even those that have support for the correct JVM, because the JVM isn't included in the distro. By splitting it up, the auto-builders will do the job of constructing the shared object on the architectures they support. Otherwise, it would require the maintainer (or someone else) to manually build on other machines. This would probably result in certain platforms being less supported in Java than they could be. It's obviously a trade-off, and debian will have to make a decision. I don't think either one's "right", but I tend to like splitting it up, even if it does pollute the package name space, and unnecessarily increase the package count. Not that my opinion makes a difference here, Peter Kahle, Debian User On Thu, Sep 12, 2002 at 08:17:26PM +0200, Robert Bihlmeyer wrote: > Ola Lundqvist <[EMAIL PROTECTED]> writes: > > > Ok. I'm thinking that maybe -java shoud be for "true" java and then > > use -jni for everything that is not "true" java. > > FWIW, perl libraries are currently packaged as ...-perl regardless of > whether they include (arch dependent) shared objects or only perl > code. Actually of the packages ending their name in '-perl', 335 are > arch:all, and 142 are not. > > -- > Robbe -- Those who would give up essential Liberty to purchase a little temporary safety, deserve neither Liberty nor safety. -- Ben Franklin || Peter M Kahle Jr || PGP Public Key on Keyservers || || [EMAIL PROTECTED] || http://www.kahlilia.org/~pkahle/ || ##===##==## msg01844/pgp0.pgp Description: PGP signature
Re: Packaging a library, with JNI and javadocs
On Thu, 2002-09-12 at 17:24, Grzegorz Prokopski wrote: > However as gcj-compiled programs are no longer java (IMO) - it > woulnd't harm if we delegate separate -gcj suffix for such > packages. The way I see it, the -gcj tag is useless and crufty. Why do I care that it's a gcj program versus a gcc program or fortran program or cobol program? All I care about is that it is architecture dependant and that the proper dependancies are on my system. Both of these features are taken care of in the control files, why do we need to overload the package name with this information? As for the -jni tag, I feel it's only useful in the specific case that I indicated I'd implement in my ocf packages. Namely, when it's a JNI (native) library only package *not* containing the corresponding .class files. I vote this way because the contents of the package are a libMyClass.so file and we want some way to tell the sysadmin "hey, this library uses JNI calling convention". If the same JNI library is packaged with the corresponding .class files, then it should use the recommended -java tag as for all intents and purposes, it's an architecture dependant Java library. -joe -- Innovation Software Group, LLC - http://www.innovationsw.com/ Business Automation Specialists UNIX, Linux and Java Training -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packaging a library, with JNI and javadocs
On Thu, Sep 05, 2002 at 11:49:26AM +0100, Ross Burton wrote: > Hi, Hi > I am considering packaging jpcsc, the Java interface to the PCSC > smartcard libraries. It consists of several parts: > > * a Java OO wrapper > * a JNI library > * Javadocs of the API > > Obviously, because of the JNI this is not a arch-independent package. I > was thinking of packaging it like so: Well the -java name extension should only (have I written that in policy?) be used for arch-independent packages. I would recommend an -jni name extension instead. > libpcsc-java > libpcsc-java-doc > > Now, I've packaged a few simple programs before but never Java. Are > there any small packages out there which use JNI I could look at for > examples? Not that I know of. You can probably be a good candidate to send me patches to the java policy. :) Regards, // Ola > Regards, > Ross > -- > Ross Burton mail: [EMAIL PROTECTED] >jabber: [EMAIL PROTECTED] > www: http://www.burtonini.com./ > PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF -- - Ola Lundqvist --- / [EMAIL PROTECTED] Annebergsslingan 37 \ | [EMAIL PROTECTED] 654 65 KARLSTAD | | +46 (0)54-10 14 30 +46 (0)70-332 1551 | | http://www.opal.dhs.org UIN/icq: 4912500 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / ---
Re: Packaging a library, with JNI and javadocs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > Well the -java name extension should only (have I written that in policy?) > be used for arch-independent packages. I would recommend an -jni name > extension instead. Hmm.. I packaged libreadline-java (a small JNI library with a couple of wrapper classes) with the -java extension as a result of (my understanding of) the java policy. :) Is there a particular reason to distinguish between native Java classes and classes with JNI implementations? As far as whoever's using them is concerned, they appear the same, no? The only issue I could think of was that you want the JVM to find the JNI library in its default search path; I resolved this by putting the corresponding C library in /usr/lib, and this appears to work fine from what testing I've done. > > Now, I've packaged a few simple programs before but never Java. Are > > there any small packages out there which use JNI I could look at for > > examples? Well, I can offer libreadline-java for you to look at, but that of course doesn't mean it's done the Right Way. Ben. :) - -- Ben Burton [EMAIL PROTECTED] | [EMAIL PROTECTED] Public Key: finger [EMAIL PROTECTED] I don't hide much, but sometimes people don't understand that I talk about them. Then we sit in the same room and they haven't got a clue. That's also the reason why I don't want to explain every detail of my work. - Tori Amos, Haaggsche Courant, 1994 -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9gDUFMQNuxza4YcERAveyAJwIoRRtUWWua+Ez5Hq2w9Z8HonJfACghY+f hhXMy4/UrZrg/Xm9HInh7jQ= =wBI7 -END PGP SIGNATURE-
Re: Packaging a library, with JNI and javadocs
Hi On Thu, Sep 12, 2002 at 04:32:34PM +1000, Ben Burton wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > > > Well the -java name extension should only (have I written that in policy?) > > be used for arch-independent packages. I would recommend an -jni name > > extension instead. > > Hmm.. I packaged libreadline-java (a small JNI library with a couple of > wrapper classes) with the -java extension as a result of (my understanding > of) the java policy. :) Well. It is mostly because to help the build daemons. Many java packages (especially in the contrib section) depend on non-packaged stuff to build the package. So arch independent -java packages are really nice. > Is there a particular reason to distinguish between native Java classes and > classes with JNI implementations? As far as whoever's using them is > concerned, they appear the same, no? I know to little about jni to answer this. > The only issue I could think of was that you want the JVM to find the JNI > library in its default search path; I resolved this by putting the > corresponding C library in /usr/lib, and this appears to work fine from what > testing I've done. If you have suggestions on how this should be done I really look forward for this kind of stuff. As I said: I do not know very much about JNI... :( > > > Now, I've packaged a few simple programs before but never Java. Are > > > there any small packages out there which use JNI I could look at for > > > examples? > > Well, I can offer libreadline-java for you to look at, but that of course > doesn't mean it's done the Right Way. :) I have now taken a _quick_ look at it. Would it be possible to use the .c stuff (arch dependent) stuff outside of java? Can the java classes be used without the .c (arch dependent) stuff? It can be used in main so non-free things is not an issue. I know I'm in favour of splitting things but I also know that all people are not. :) Regards, // Ola > Ben. :) > > - -- > > Ben Burton > [EMAIL PROTECTED] | [EMAIL PROTECTED] > Public Key: finger [EMAIL PROTECTED] > > I don't hide much, but sometimes people don't understand that I > talk about them. Then we sit in the same room and they haven't got a clue. > That's also the reason why I don't want to explain every detail of my work. > - Tori Amos, Haaggsche Courant, 1994 > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.0.7 (GNU/Linux) > > iD8DBQE9gDUFMQNuxza4YcERAveyAJwIoRRtUWWua+Ez5Hq2w9Z8HonJfACghY+f > hhXMy4/UrZrg/Xm9HInh7jQ= > =wBI7 > -END PGP SIGNATURE- > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > -- - Ola Lundqvist --- / [EMAIL PROTECTED] Annebergsslingan 37 \ | [EMAIL PROTECTED] 654 65 KARLSTAD | | +46 (0)54-10 14 30 +46 (0)70-332 1551 | | http://www.opal.dhs.org UIN/icq: 4912500 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / ---
Re: Packaging a library, with JNI and javadocs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > Well. It is mostly because to help the build daemons. Many java packages > (especially in the contrib section) depend on non-packaged stuff to build > the package. So arch independent -java packages are really nice. I'm not sure I see how this helps the build daemons. If something depends on non-packaged stuff at build time, the build daemons can't build it anyway since they won't have the build dependencies available to them. If something doesn't depend on non-packaged stuff at build time then the build daemons should be fine regardless of architecture. > I have now taken a _quick_ look at it. Would it be possible to use the > .c stuff (arch dependent) stuff outside of java? Not really. The C library contains java-specific wrappers. In fact, all that's really in the libreadline-java C library is java-specific wrappers to the usual libedit routines. > Can the java classes be used without the .c (arch dependent) stuff? No. They will not function without the C library (the JVM will throw an exception if the C library is not available). > I know I'm in favour of splitting things but I also know that all people > are not. :) I do believe in this instance that neither the java classes nor the C library make sense without the other. Ben. :) - -- Ben Burton [EMAIL PROTECTED] | [EMAIL PROTECTED] Public Key: finger [EMAIL PROTECTED] To love oneself is the beginning of a lifelong romance. - Oscar Wilde -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9gJKjMQNuxza4YcERAoq5AJ9pV9P8GLKNQx4iChrj4cC2XcQ9aQCgmpFe p6haJIjTU/7MV1CyK0vcgcY= =gCmJ -END PGP SIGNATURE-
Re: Packaging a library, with JNI and javadocs
Appropriate timing for me. I was planning on packaging portions of OCF, which will include some JNI libraries. On Thu, 2002-09-12 at 09:12, Ben Burton wrote: > > Well. It is mostly because to help the build daemons. Many java packages > > (especially in the contrib section) depend on non-packaged stuff to build > > the package. So arch independent -java packages are really nice. > > I'm not sure I see how this helps the build daemons. If something depends on > non-packaged stuff at build time, the build daemons can't build it anyway > since they won't have the build dependencies available to them. If something > doesn't depend on non-packaged stuff at build time then the build daemons > should be fine regardless of architecture. I'm in favor of using the -java for JNI + supporting java classes. After all, it's still a Java library - it's just architecture dependant. Instead of using -jni, I vote the package be built architecture dependant. eg. as opposed to _all.deb it's a _i386.deb. > > I have now taken a _quick_ look at it. Would it be possible to use the > > .c stuff (arch dependent) stuff outside of java? > > Not really. The C library contains java-specific wrappers. In fact, all > that's really in the libreadline-java C library is java-specific wrappers to > the usual libedit routines. > > > Can the java classes be used without the .c (arch dependent) stuff? > > No. They will not function without the C library (the JVM will throw an > exception if the C library is not available). They cannot be used but can be built. > > I know I'm in favour of splitting things but I also know that all people > > are not. :) > > I do believe in this instance that neither the java classes nor the C library > make sense without the other. In my particular case, the java source and the JNI source come from two upstreams. I was planning to separate the debian packages like so: - arch-dependant JNI libraries go into libocf-pcsc and similar, recommending (or depending on - I'll accept suggestions) libocf-pcsc-java (or similar). - arch-independant java classes will go into libocf-pcsc-java and similar, depending on libocf-pcsc. If the Java and JNI sources come from the same upstream, I think it still makes sense to keep the packages together, just making an architecture dependant package. Or you can go my route and separate them. IMHO, using -jni seems redundant. Either way though, I'll follow common convention or Policy where possible. -joe -- Innovation Software Group, LLC - http://www.innovationsw.com/ Business Automation Specialists UNIX, Linux and Java Training
Re: Packaging a library, with JNI and javadocs
On Thu, Sep 12, 2002 at 10:00:03AM -0400, Joe Phillips wrote: > I'm in favor of using the -java for JNI + supporting java classes. > After all, it's still a Java library - it's just architecture > dependant. Instead of using -jni, I vote the package be built > architecture dependant. eg. as opposed to _all.deb it's a _i386.deb. I second this. It should be put in the Java policy this way. There has been a discussion about native-compiled Java code using gcj on this list some month ago but no consensus was reached. Maybe this could be resolved together with the JNI matter now? Greetings, Stefan Gybas
Re: Packaging a library, with JNI and javadocs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > I'm in favor of using the -java for JNI + supporting java classes. FWIW, I support this also. But to go into more detail: > - arch-dependant JNI libraries go into libocf-pcsc and similar, > recommending (or depending on - I'll accept suggestions) > libocf-pcsc-java (or similar). In this case however I might argue for something clear in the arch-dependant package name that it's a JNI library, eg., libocf-pcsc-jni instead of just libocf-pcsc. The main reason being that (I presume) the C library provides java-specific functions and so there seems little reason to use it outside the context of JNI. So I guess my stance is then to either: - - use a single package named libfoo-java with both the java classes and the C library, or: - - use two packages, these being libfoo-java containing the java classes and libfoo-jni containing the C library. I don't see any particular need to favour only one of these options as policy; I can see circumstances where each option (splitting vs not splitting) has its benefits. Ben. - -- Ben Burton [EMAIL PROTECTED] | [EMAIL PROTECTED] Public Key: finger [EMAIL PROTECTED] A cigarette is the perfect type of a perfect pleasure. It is exquisite, and it leaves one unsatisfied. What more can one want? - Oscar Wilde -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9gKY+MQNuxza4YcERAieIAJ9tkfFPaRC3Bf5eXY3ixFhAIgvkFACgiFpi YrMikfzP4kcqwilABtpxoIg= =hjxN -END PGP SIGNATURE-
Re: Packaging a library, with JNI and javadocs
On Thu, 2002-09-12 at 10:35, Ben Burton wrote: > So I guess my stance is then to either: > - - use a single package named libfoo-java with both the java classes and the > C > library, or: > - - use two packages, these being libfoo-java containing the java classes and > libfoo-jni containing the C library. > > I don't see any particular need to favour only one of these options as > policy; > I can see circumstances where each option (splitting vs not splitting) has > its benefits. Your suggestions seem reasonable to me. -joe -- Innovation Software Group, LLC - http://www.innovationsw.com/ Business Automation Specialists UNIX, Linux and Java Training
Re: Packaging a library, with JNI and javadocs
On Thu, Sep 12, 2002 at 04:15:13PM +0200, Stefan Gybas wrote: > On Thu, Sep 12, 2002 at 10:00:03AM -0400, Joe Phillips wrote: > > > I'm in favor of using the -java for JNI + supporting java classes. > > After all, it's still a Java library - it's just architecture > > dependant. Instead of using -jni, I vote the package be built > > architecture dependant. eg. as opposed to _all.deb it's a _i386.deb. > > I second this. It should be put in the Java policy this way. > > There has been a discussion about native-compiled Java code using > gcj on this list some month ago but no consensus was reached. Maybe > this could be resolved together with the JNI matter now? They seem very similar so yes it should be resolved. :) Regards. // Ola > Greetings, > Stefan Gybas > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > -- - Ola Lundqvist --- / [EMAIL PROTECTED] Annebergsslingan 37 \ | [EMAIL PROTECTED] 654 65 KARLSTAD | | +46 (0)54-10 14 30 +46 (0)70-332 1551 | | http://www.opal.dhs.org UIN/icq: 4912500 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / ---
Re: Packaging a library, with JNI and javadocs
Hi On Fri, Sep 13, 2002 at 12:35:42AM +1000, Ben Burton wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > > > I'm in favor of using the -java for JNI + supporting java classes. > > FWIW, I support this also. But to go into more detail: I'd like to extend this some. > > - arch-dependant JNI libraries go into libocf-pcsc and similar, > > recommending (or depending on - I'll accept suggestions) > > libocf-pcsc-java (or similar). > > In this case however I might argue for something clear in the arch-dependant > package name that it's a JNI library, eg., libocf-pcsc-jni instead of just > libocf-pcsc. I second this. I also suggest that gcj files go to a package named -gjc. But I also think that the policy should say 'should' and explain that it in some situations (if the packages are small and have few dependencies) it might be better to have just one package. > The main reason being that (I presume) the C library provides java-specific > functions and so there seems little reason to use it outside the context of > JNI. > > So I guess my stance is then to either: > - - use a single package named libfoo-java with both the java classes and the > C > library, or: > - - use two packages, these being libfoo-java containing the java classes and > libfoo-jni containing the C library. And I say that the default thing should be the second one (with addition for -gcj) unless the package is very small and have very little extra in its dependencies. Is there something called dependency file size? > I don't see any particular need to favour only one of these options as > policy; > I can see circumstances where each option (splitting vs not splitting) has > its benefits. Agreed. It should be mentioned in the policy. Regards, // Ola > Ben. > > - -- > > Ben Burton > [EMAIL PROTECTED] | [EMAIL PROTECTED] > Public Key: finger [EMAIL PROTECTED] > > A cigarette is the perfect type of a perfect pleasure. It is exquisite, > and it leaves one unsatisfied. What more can one want? > - Oscar Wilde > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.0.7 (GNU/Linux) > > iD8DBQE9gKY+MQNuxza4YcERAieIAJ9tkfFPaRC3Bf5eXY3ixFhAIgvkFACgiFpi > YrMikfzP4kcqwilABtpxoIg= > =hjxN > -END PGP SIGNATURE- > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > -- - Ola Lundqvist --- / [EMAIL PROTECTED] Annebergsslingan 37 \ | [EMAIL PROTECTED] 654 65 KARLSTAD | | +46 (0)54-10 14 30 +46 (0)70-332 1551 | | http://www.opal.dhs.org UIN/icq: 4912500 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / ---
Re: Packaging a library, with JNI and javadocs
On Thu, Sep 12, 2002 at 11:12:00PM +1000, Ben Burton wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > > > Well. It is mostly because to help the build daemons. Many java packages > > (especially in the contrib section) depend on non-packaged stuff to build > > the package. So arch independent -java packages are really nice. > > I'm not sure I see how this helps the build daemons. If something depends on > non-packaged stuff at build time, the build daemons can't build it anyway > since they won't have the build dependencies available to them. If something > doesn't depend on non-packaged stuff at build time then the build daemons > should be fine regardless of architecture. It was recently a discussion on debian-policy about this. They was discussing build-arch vs build-indep. So no right now it is not really useful but maybe in a short time. > > I have now taken a _quick_ look at it. Would it be possible to use the > > .c stuff (arch dependent) stuff outside of java? > > Not really. The C library contains java-specific wrappers. In fact, all > that's really in the libreadline-java C library is java-specific wrappers to > the usual libedit routines. > > > Can the java classes be used without the .c (arch dependent) stuff? > > No. They will not function without the C library (the JVM will throw an > exception if the C library is not available). Ok. I'm thinking that maybe -java shoud be for "true" java and then use -jni for everything that is not "true" java. > > I know I'm in favour of splitting things but I also know that all people > > are not. :) > > I do believe in this instance that neither the java classes nor the C library > make sense without the other. Now I'm more convinced of using -jni as extension. Yes I know I'm changing constantly ;) Regards, // Ola > Ben. :) > > - -- > > Ben Burton > [EMAIL PROTECTED] | [EMAIL PROTECTED] > Public Key: finger [EMAIL PROTECTED] > > To love oneself is the beginning of a lifelong romance. > - Oscar Wilde > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.0.7 (GNU/Linux) > > iD8DBQE9gJKjMQNuxza4YcERAoq5AJ9pV9P8GLKNQx4iChrj4cC2XcQ9aQCgmpFe > p6haJIjTU/7MV1CyK0vcgcY= > =gCmJ > -END PGP SIGNATURE- > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > -- - Ola Lundqvist --- / [EMAIL PROTECTED] Annebergsslingan 37 \ | [EMAIL PROTECTED] 654 65 KARLSTAD | | +46 (0)54-10 14 30 +46 (0)70-332 1551 | | http://www.opal.dhs.org UIN/icq: 4912500 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / ---
Re: Packaging a library, with JNI and javadocs
Hi again. I have a new (very similar to the last one) that should go into the policy. JNI, gcj and other architecture dependend versions of java: JNI libraries consist of something that is architecture dependent and possibly(?) architecture independent java classes. These should go into a packages called libfoo-jni for the architecture dependent files. Java classes and other architecture independent stuff can/should be split into libfoo-java package if some/all of it can be used without the architecture dependent files. When gcj libraries is compiled from java source, these architecture dependent library files should go into an architecture dependent package called libfoo-gcj. Architecture independent java classes should/must be split into a corresponding libfoo-java package. Is this something that can go into policy (yes clarifications can be in place so please comment it)? I assume that it is more to say about jni and gcj but this is at least a start. :) Regards, // Ola On Thu, Sep 12, 2002 at 06:14:45PM +0200, Ola Lundqvist wrote: > > FWIW, I support this also. But to go into more detail: > > I'd like to extend this some. > > > > - arch-dependant JNI libraries go into libocf-pcsc and similar, > > > recommending (or depending on - I'll accept suggestions) > > > libocf-pcsc-java (or similar). > > > > In this case however I might argue for something clear in the > > arch-dependant > > package name that it's a JNI library, eg., libocf-pcsc-jni instead of just > > libocf-pcsc. > > I second this. > > I also suggest that gcj files go to a package named -gjc. But I also think > that the policy should say 'should' and explain that it in some situations > (if the packages are small and have few dependencies) it might be better > to have just one package. > > > The main reason being that (I presume) the C library provides java-specific > > functions and so there seems little reason to use it outside the context of > > JNI. > > > > So I guess my stance is then to either: > > - - use a single package named libfoo-java with both the java classes and > > the C > > library, or: > > - - use two packages, these being libfoo-java containing the java classes > > and > > libfoo-jni containing the C library. > > And I say that the default thing should be the second one (with addition for > -gcj) unless the package is very small and have very little extra in its > dependencies. Is there something called dependency file size? > > > I don't see any particular need to favour only one of these options as > > policy; > > I can see circumstances where each option (splitting vs not splitting) has > > its benefits. > > Agreed. It should be mentioned in the policy. > > Regards, > > // Ola > > > Ben. > > > > - -- > > > > Ben Burton > > [EMAIL PROTECTED] | [EMAIL PROTECTED] > > Public Key: finger [EMAIL PROTECTED] > > > > A cigarette is the perfect type of a perfect pleasure. It is exquisite, > > and it leaves one unsatisfied. What more can one want? > > - Oscar Wilde > > > > -BEGIN PGP SIGNATURE- > > Version: GnuPG v1.0.7 (GNU/Linux) > > > > iD8DBQE9gKY+MQNuxza4YcERAieIAJ9tkfFPaRC3Bf5eXY3ixFhAIgvkFACgiFpi > > YrMikfzP4kcqwilABtpxoIg= > > =hjxN > > -END PGP SIGNATURE- > > > > > > -- > > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > > > -- > - Ola Lundqvist --- > / [EMAIL PROTECTED] Annebergsslingan 37 \ > | [EMAIL PROTECTED] 654 65 KARLSTAD | > | +46 (0)54-10 14 30 +46 (0)70-332 1551 | > | http://www.opal.dhs.org UIN/icq: 4912500 | > \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / > --- > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > -- - Ola Lundqvist --- / [EMAIL PROTECTED] Annebergsslingan 37 \ | [EMAIL PROTECTED] 654 65 KARLSTAD | | +46 (0)54-10 14 30 +46 (0)70-332 1551 | | http://www.opal.dhs.org UIN/icq: 4912500 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / ---
Re: Packaging a library, with JNI and javadocs
On Thu, 2002-09-12 at 17:20, Ola Lundqvist wrote: > Now I'm more convinced of using -jni as extension. Yes I know I'm changing > constantly ;) As I started this thread, I suppose I best say something. I am also in favour of the pure approach -- pure Java libraries in libfoo-java, which depends on architecture dependant libraries in libfoo-jni. Ross -- Ross Burton mail: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] www: http://www.burtonini.com./ PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF signature.asc Description: This is a digitally signed message part
Re: Packaging a library, with JNI and javadocs
Ola Lundqvist <[EMAIL PROTECTED]> writes: > Ok. I'm thinking that maybe -java shoud be for "true" java and then > use -jni for everything that is not "true" java. FWIW, perl libraries are currently packaged as ...-perl regardless of whether they include (arch dependent) shared objects or only perl code. Actually of the packages ending their name in '-perl', 335 are arch:all, and 142 are not. -- Robbe signature.ng Description: PGP signature
Re: Packaging a library, with JNI and javadocs
W liście z czw, 12-09-2002, godz. 20:17, Robert Bihlmeyer pisze: > Ola Lundqvist <[EMAIL PROTECTED]> writes: > > > Ok. I'm thinking that maybe -java shoud be for "true" java and then > > use -jni for everything that is not "true" java. > > FWIW, perl libraries are currently packaged as ...-perl regardless of > whether they include (arch dependent) shared objects or only perl > code. Actually of the packages ending their name in '-perl', 335 are > arch:all, and 142 are not. I'd like to say my opinion. I think that using -java suffix is OK as long, as the code is such package can be used by every standard JVM/classlib. So it seems doubful if we need -jni suffix if such code can be run by every ordinary JVM (but I would not be against such suffix if the others want to go this way). However as gcj-compiled programs are no longer java (IMO) - it woulnd't harm if we delegate separate -gcj suffix for such packages. Regards Grzegorz B. Prokopski
Re: Packaging a library, with JNI and javadocs
The problem here is that a package that includes jni and Java code probably can't be auto-built on all architectures, even those that have support for the correct JVM, because the JVM isn't included in the distro. By splitting it up, the auto-builders will do the job of constructing the shared object on the architectures they support. Otherwise, it would require the maintainer (or someone else) to manually build on other machines. This would probably result in certain platforms being less supported in Java than they could be. It's obviously a trade-off, and debian will have to make a decision. I don't think either one's "right", but I tend to like splitting it up, even if it does pollute the package name space, and unnecessarily increase the package count. Not that my opinion makes a difference here, Peter Kahle, Debian User On Thu, Sep 12, 2002 at 08:17:26PM +0200, Robert Bihlmeyer wrote: > Ola Lundqvist <[EMAIL PROTECTED]> writes: > > > Ok. I'm thinking that maybe -java shoud be for "true" java and then > > use -jni for everything that is not "true" java. > > FWIW, perl libraries are currently packaged as ...-perl regardless of > whether they include (arch dependent) shared objects or only perl > code. Actually of the packages ending their name in '-perl', 335 are > arch:all, and 142 are not. > > -- > Robbe -- Those who would give up essential Liberty to purchase a little temporary safety, deserve neither Liberty nor safety. -- Ben Franklin || Peter M Kahle Jr || PGP Public Key on Keyservers || || [EMAIL PROTECTED] || http://www.kahlilia.org/~pkahle/ || ##===##==## pgpdTq8lSFgjF.pgp Description: PGP signature
Re: Packaging a library, with JNI and javadocs
On Thu, 2002-09-12 at 17:24, Grzegorz Prokopski wrote: > However as gcj-compiled programs are no longer java (IMO) - it > woulnd't harm if we delegate separate -gcj suffix for such > packages. The way I see it, the -gcj tag is useless and crufty. Why do I care that it's a gcj program versus a gcc program or fortran program or cobol program? All I care about is that it is architecture dependant and that the proper dependancies are on my system. Both of these features are taken care of in the control files, why do we need to overload the package name with this information? As for the -jni tag, I feel it's only useful in the specific case that I indicated I'd implement in my ocf packages. Namely, when it's a JNI (native) library only package *not* containing the corresponding .class files. I vote this way because the contents of the package are a libMyClass.so file and we want some way to tell the sysadmin "hey, this library uses JNI calling convention". If the same JNI library is packaged with the corresponding .class files, then it should use the recommended -java tag as for all intents and purposes, it's an architecture dependant Java library. -joe -- Innovation Software Group, LLC - http://www.innovationsw.com/ Business Automation Specialists UNIX, Linux and Java Training
