On Fri, Jan 23, 2004 at 12:15:27AM -0600, Adam Majer wrote:
> On Tue, Jan 20, 2004 at 02:00:12PM -0500, Andrew Pimlott wrote:
> > Irrespective of the testing issue, it seems obvious that just as the
> > jikes source package is the wrong place for these wrappers (why
> > sho
On Sat, Jan 17, 2004 at 12:44:34AM -0500, Grzegorz B. Prokopski wrote:
> These JVMs are encouraged and free to move these one-file wrappers to
> their own packages (which in turn will probably Depend: on jikes or
> make it Recommend: and make wrappers fail gracefully or sth. like that).
>
> I seek
On Tue, Jul 29, 2003 at 03:45:08PM +0200, Stefan Gybas wrote:
> Andrew Pimlott wrote:
>
> >You might want official builds to always use the same compiler, but
> >there's no reason not to make it convenient for others to use their
> >preferred compiler. Especially w
On Tue, Jul 29, 2003 at 08:23:23PM +0200, Stefan Gybas wrote:
> It is just for building the package. I don't think that most users will
> rebuild the Java packages, especially since they are architecture
> independent. You also need a lot of -dev packages (and gcc) for
> rebuilding C and C++ pac
On Tue, Jul 29, 2003 at 03:45:08PM +0200, Stefan Gybas wrote:
> Andrew Pimlott wrote:
>
> >You might want official builds to always use the same compiler, but
> >there's no reason not to make it convenient for others to use their
> >preferred compiler. Especially w
On Tue, Jul 29, 2003 at 08:23:23PM +0200, Stefan Gybas wrote:
> It is just for building the package. I don't think that most users will
> rebuild the Java packages, especially since they are architecture
> independent. You also need a lot of -dev packages (and gcc) for
> rebuilding C and C++ pac
On Mon, Jul 28, 2003 at 07:13:47PM +0200, Stefan Gybas wrote:
> That's exactly the purpose. A build dependency for a JVM should be
> specific, see http://pkg-java.alioth.debian.org/building.html for the
> reasons.
You might want official builds to always use the same compiler, but
there's no rea
On Mon, Jul 28, 2003 at 07:13:47PM +0200, Stefan Gybas wrote:
> That's exactly the purpose. A build dependency for a JVM should be
> specific, see http://pkg-java.alioth.debian.org/building.html for the
> reasons.
You might want official builds to always use the same compiler, but
there's no rea
On Mon, Jun 30, 2003 at 08:19:19AM +1000, Ben Burton wrote:
> I can't tell you how to determine which gcc a binary was compiled with,
> but I can tell you that you're not just doing something stupid.
> Downloading a -gcc3.2 tarball from Blackdown certainly fixed my JNI crash,
> which I am told was
The current unstable mozilla-browser says (in README.Debian)
5. using Java. (You should use plugin which compiled with gcc-3.2)
You should install j2re1.4 (BlackDown Java Linux) package from
deb ftp://ftp.tux.org/pub/java/debian unstable main non-free
or other mirrors.
Bu
On Sat, Jan 11, 2003 at 01:35:53PM -0700, Patrick Tullmann wrote:
> It occurred to me that these tools (ant, jetty, etc.) are only
> dependent upon a specific class name (i.e., com.sun.tools.javac.Main),
> and what they really want is whatever jar file contains that class.
>
> It seems to me that
On Sat, Jan 11, 2003 at 03:07:24PM +, Greg Wilkins wrote:
> Note that jasper2 no longer directly uses tools.jar, as it uses
> ant to do all it's compiling. Thus whatever ant.jar needs to find
> tools.jar is what jasper and hence tomcat needs.
>
> So hopefully the tools.jar dependancy will soo
On Sat, Jan 11, 2003 at 03:07:24PM +, Greg Wilkins wrote:
> Note that jasper2 no longer directly uses tools.jar, as it uses
> ant to do all it's compiling. Thus whatever ant.jar needs to find
> tools.jar is what jasper and hence tomcat needs.
>
> So hopefully the tools.jar dependancy will soo
On Fri, Jan 10, 2003 at 07:16:22PM -0500, Joe Phillips wrote:
> On Thu, 2003-01-02 at 18:14, Andrew Pimlott wrote:
> > Any package that depends on JAVA_HOME should be taken out and shot.
> > Or, more politely, when it is packaged for Debian, those portions
> > should be exci
On Fri, Jan 10, 2003 at 07:16:22PM -0500, Joe Phillips wrote:
> On Thu, 2003-01-02 at 18:14, Andrew Pimlott wrote:
> > Any package that depends on JAVA_HOME should be taken out and shot.
> > Or, more politely, when it is packaged for Debian, those portions
> > should be exci
Oooh--I'll answer this!
On Thu, Jan 02, 2003 at 05:03:32PM -0500, Joe Phillips wrote:
> I've seen package after package (mine included) depend on a
> JAVA_HOME environment variable set somewhere, in some script.
> Most packages seem to use a config file or init-script to define a
> local JAVA_HOME
Oooh--I'll answer this!
On Thu, Jan 02, 2003 at 05:03:32PM -0500, Joe Phillips wrote:
> I've seen package after package (mine included) depend on a
> JAVA_HOME environment variable set somewhere, in some script.
> Most packages seem to use a config file or init-script to define a
> local JAVA_HOME
On Sat, May 18, 2002 at 10:53:29AM -0700, T. Alexander Popiel wrote:
> 5. Would it be useful to folks if I made available a second dh_java*
>tool for taking a list of entry-point .classes and putting them
>(and all the .classes they depended on, excluding ones already
>in indicated .jar
On Sat, May 18, 2002 at 10:53:29AM -0700, T. Alexander Popiel wrote:
> 5. Would it be useful to folks if I made available a second dh_java*
>tool for taking a list of entry-point .classes and putting them
>(and all the .classes they depended on, excluding ones already
>in indicated .ja
On Sun, May 12, 2002 at 09:15:31PM -0700, Jim Pick wrote:
> I think the Debian Java policy, as currently stated, is slightly flawed,
> as it tries to satisfy two goals that aren't completely orthogonal:
>
> 1) To get as much free Java software into Debian as possible, that runs
> without non-
On Sun, May 12, 2002 at 09:15:31PM -0700, Jim Pick wrote:
> I think the Debian Java policy, as currently stated, is slightly flawed,
> as it tries to satisfy two goals that aren't completely orthogonal:
>
> 1) To get as much free Java software into Debian as possible, that runs
> without non
On Sun, May 12, 2002 at 05:03:54PM -0700, Stephen Zander wrote:
> >>>>> "Andrew" == Andrew Pimlott <[EMAIL PROTECTED]> writes:
> Andrew> No it's not. But you can use the gcj produced .so files
> Andrew> with gcj. If I do all my Java
On Sun, May 12, 2002 at 04:28:56PM -0700, Stephen Zander wrote:
> >>>>> "Andrew" == Andrew Pimlott <[EMAIL PROTECTED]> writes:
> Andrew> To clarify, I'm talking about Java code compiled (eg, by
> Andrew> gcj) into architecture-specific mac
On Sun, May 12, 2002 at 05:03:54PM -0700, Stephen Zander wrote:
> >>>>> "Andrew" == Andrew Pimlott <[EMAIL PROTECTED]> writes:
> Andrew> No it's not. But you can use the gcj produced .so files
> Andrew> with gcj. If I do all my Java
> > If the Java code depends on code written in a "native" language
> > (eg, via JNI), the compiled .class files should be delivered in
> > an "Architecture: all" package that depends on an
> > architecture-specific package containing the compiled native
> > code.
> Looks like t
On Sun, May 12, 2002 at 04:28:56PM -0700, Stephen Zander wrote:
> >>>>> "Andrew" == Andrew Pimlott <[EMAIL PROTECTED]> writes:
> Andrew> To clarify, I'm talking about Java code compiled (eg, by
> Andrew> gcj) into architecture-specif
On Sun, May 12, 2002 at 10:31:43PM +0200, Egon Willighagen wrote:
> On Sunday 12 May 2002 22:00, Andrew Pimlott wrote:
> > Ok, then it is just a question of naming. Say my foo library can be
> > compiled to .class files and GCJ .so files. One option is to
> > package both
On Sun, May 12, 2002 at 09:40:05PM +0200, Ola Lundqvist wrote:
> I disagree on that class files should be placed in a -dev package for the
> same reason as I want every jar file to be placed in /usr/share/java
> (maybe with an exception for jvm:s). You should always be allowed
> to use the classes
On Sun, May 12, 2002 at 09:16:37PM +0200, Ola Lundqvist wrote:
> Java code is supposed to be
> portable. If you compile it to machine binaries it is no longer a
> java program and should not be packaged as a such.
You've been listening to too much Sun marketing. :-)
Please give a rational reason
> > If the Java code depends on code written in a "native" language
> > (eg, via JNI), the compiled .class files should be delivered in
> > an "Architecture: all" package that depends on an
> > architecture-specific package containing the compiled native
> > code.
> Looks like
On Sat, May 11, 2002 at 05:41:29PM +0200, Ola Lundqvist wrote:
> http://people.debian.org/~opal/java/policy.html/policy.html
The following,
Both are shipped as Java bytecode (*.class files, packaged in a
*.jar archive) and with an "Architecture: all" since Java
bytecode is supposed t
On Sun, May 12, 2002 at 10:31:43PM +0200, Egon Willighagen wrote:
> On Sunday 12 May 2002 22:00, Andrew Pimlott wrote:
> > Ok, then it is just a question of naming. Say my foo library can be
> > compiled to .class files and GCJ .so files. One option is to
> > package both
On Sun, May 12, 2002 at 09:40:05PM +0200, Ola Lundqvist wrote:
> I disagree on that class files should be placed in a -dev package for the
> same reason as I want every jar file to be placed in /usr/share/java
> (maybe with an exception for jvm:s). You should always be allowed
> to use the classes
On Sun, May 12, 2002 at 09:16:37PM +0200, Ola Lundqvist wrote:
> Java code is supposed to be
> portable. If you compile it to machine binaries it is no longer a
> java program and should not be packaged as a such.
You've been listening to too much Sun marketing. :-)
Please give a rational reason
On Sat, May 11, 2002 at 05:41:29PM +0200, Ola Lundqvist wrote:
> http://people.debian.org/~opal/java/policy.html/policy.html
The following,
Both are shipped as Java bytecode (*.class files, packaged in a
*.jar archive) and with an "Architecture: all" since Java
bytecode is supposed
On Wed, Apr 03, 2002 at 05:19:29PM -0800, Joe Emenaker wrote:
> On a related note
This is exactly the Java registry idea that's been discussed here in
the past. Check the archives from the end of last year. You might
in particular see Ben Burton's message with subject "JVM Registry:
Impleme
On Wed, Apr 03, 2002 at 05:19:29PM -0800, Joe Emenaker wrote:
> On a related note
This is exactly the Java registry idea that's been discussed here in
the past. Check the archives from the end of last year. You might
in particular see Ben Burton's message with subject "JVM Registry:
Implem
On Tue, Apr 02, 2002 at 08:43:55PM +0200, Robert Bihlmeyer wrote:
> [EMAIL PROTECTED] writes:
>
> > I also think the jikes-kaffe, etc proposals are silly: You should
> > be able to achieve the same with a simple "jikes -bootclasspath
> > /wherever/kaffe/puts/Klasses.jar".
>
> Oh, you don't seem
On Tue, Apr 02, 2002 at 08:43:55PM +0200, Robert Bihlmeyer wrote:
> [EMAIL PROTECTED] writes:
>
> > I also think the jikes-kaffe, etc proposals are silly: You should
> > be able to achieve the same with a simple "jikes -bootclasspath
> > /wherever/kaffe/puts/Klasses.jar".
>
> Oh, you don't seem
On Tue, Nov 27, 2001 at 07:14:50PM +0100, Guillaume Rousse wrote:
> Initial proposition had two points:
> 1) always split javadoc-generated documentation in another package
> 2) standardize javadoc location to cross-link generated documentation
> There have been opposition againt 1), so lets' drop
On Tue, Nov 27, 2001 at 07:14:50PM +0100, Guillaume Rousse wrote:
> Initial proposition had two points:
> 1) always split javadoc-generated documentation in another package
> 2) standardize javadoc location to cross-link generated documentation
> There have been opposition againt 1), so lets' drop
On Mon, Nov 26, 2001 at 06:39:38PM +0100, Guillaume Rousse wrote:
> Ainsi parlait Andrew Pimlott :
> > What exactly do you mean by "standard documentation"? I assume you
> > mean "non-developer documentation". In this case, you are
> > presen
On Wed, Nov 14, 2001 at 11:23:52PM +0100, Max Kellermann wrote:
> I have made a Debian package containing an experimental java
> classpath builder
Hi Max. I took a quick look at your package. I think the idea is
basically right, but I would be somewhat disappointed if we couldn't
fit the necessa
[ Responding to an old message. Sorry. ]
On Fri, Nov 09, 2001 at 12:29:44AM -0800, Kevin A. Burton wrote:
> Adam Heath <[EMAIL PROTECTED]> writes:
> > Someone else writes:
> > > Due to the WORA nature of Java applications, a lot of projects assume they
> > > are the only package management system
On Mon, Nov 26, 2001 at 06:39:38PM +0100, Guillaume Rousse wrote:
> Ainsi parlait Andrew Pimlott :
> > What exactly do you mean by "standard documentation"? I assume you
> > mean "non-developer documentation". In this case, you are
> > presen
On Wed, Nov 14, 2001 at 11:23:52PM +0100, Max Kellermann wrote:
> I have made a Debian package containing an experimental java
> classpath builder
Hi Max. I took a quick look at your package. I think the idea is
basically right, but I would be somewhat disappointed if we couldn't
fit the necess
[ Responding to an old message. Sorry. ]
On Fri, Nov 09, 2001 at 12:29:44AM -0800, Kevin A. Burton wrote:
> Adam Heath <[EMAIL PROTECTED]> writes:
> > Someone else writes:
> > > Due to the WORA nature of Java applications, a lot of projects assume they
> > > are the only package management syste
On Sun, Nov 25, 2001 at 10:48:43AM +0100, Ola Lundqvist wrote:
> But if we want to distinguish between doc and javadoc on the filesystem
> level I think it is good to separate it on the package level too.
Why? For example, glibc-doc contains both man and info files. The
only common reason for di
On Fri, Nov 23, 2001 at 12:21:57PM +0100, Guillaume Rousse wrote:
> According to discussion, it seems we agreed on following points:
I didn't realize there was consensus, though that may be because
I've been skimming lots of back mail. I don't think this proposal
has much merit.
> - have standar
On Sun, Nov 25, 2001 at 10:48:43AM +0100, Ola Lundqvist wrote:
> But if we want to distinguish between doc and javadoc on the filesystem
> level I think it is good to separate it on the package level too.
Why? For example, glibc-doc contains both man and info files. The
only common reason for d
On Fri, Nov 23, 2001 at 12:21:57PM +0100, Guillaume Rousse wrote:
> According to discussion, it seems we agreed on following points:
I didn't realize there was consensus, though that may be because
I've been skimming lots of back mail. I don't think this proposal
has much merit.
> - have standa
[ Responding to old mail. The issue was whether Java packages
should depend on both java-virtual-machine and java1/2-runtime. ]
On Fri, Oct 05, 2001 at 05:18:29PM +0200, Ola Lundqvist wrote:
> > If all jvm packages out there specified whether they were java1-runtime
> > or java2-runtime c
[ Responding to old mail. The issue was whether Java packages
should depend on both java-virtual-machine and java1/2-runtime. ]
On Fri, Oct 05, 2001 at 05:18:29PM +0200, Ola Lundqvist wrote:
> > If all jvm packages out there specified whether they were java1-runtime
> > or java2-runtime
On Thu, Sep 13, 2001 at 08:55:04PM +1000, jeff wrote:
> But I'll spare you that ranting; let's just say I think it's a
> horrifically bad idea to have a free-for-all in one's classpath.
I tend to agree, though I should point out that the opposite view
has support. For example, Per Bothner said in
On Fri, Sep 14, 2001 at 06:18:19PM +0200, Ola Lundqvist wrote:
> The problem I was talking about was that some packages can
> provide and depend on specific jar packages, and maybe with
> a specific version of that package.
>
> So why not just "Provides: foo.jar, bar.jar" and then depend on the
>
[ Another late reply from me. ]
My gut reaction is that this is the right thing.
Currently, I think most of us would agree, Debian packaging of Java
software is not that successful. I think this is in part due to the
variety of available implementations of various portions of the
various Java pl
On Thu, Sep 13, 2001 at 08:55:04PM +1000, jeff wrote:
> But I'll spare you that ranting; let's just say I think it's a
> horrifically bad idea to have a free-for-all in one's classpath.
I tend to agree, though I should point out that the opposite view
has support. For example, Per Bothner said i
On Fri, Sep 14, 2001 at 06:18:19PM +0200, Ola Lundqvist wrote:
> The problem I was talking about was that some packages can
> provide and depend on specific jar packages, and maybe with
> a specific version of that package.
>
> So why not just "Provides: foo.jar, bar.jar" and then depend on the
>
[ Another late reply from me. ]
My gut reaction is that this is the right thing.
Currently, I think most of us would agree, Debian packaging of Java
software is not that successful. I think this is in part due to the
variety of available implementations of various portions of the
various Java p
On Fri, Sep 07, 2001 at 05:41:08PM -0500, Ben Burton wrote:
>
> > I don't see much value in "java2-virtual-machine" unless it actually
> > means a complete Java 2 runtime environment.
> >
> > Our new packages currently provide j2re and j2re..
>
> The idea is that much as I love the blackdown port
[ Late reply due to backlog. ]
On Sun, Sep 02, 2001 at 06:13:04PM -0500, Ben Burton wrote:
> Okay. I have a new proposal for java-common, namely the scripts
> /usr/bin/whichjava and /usr/bin/whichjavac.
>
> What these do is take the given Java interpreter/compiler and spit out
> properties suc
On Fri, Sep 07, 2001 at 05:41:08PM -0500, Ben Burton wrote:
>
> > I don't see much value in "java2-virtual-machine" unless it actually
> > means a complete Java 2 runtime environment.
> >
> > Our new packages currently provide j2re and j2re..
>
> The idea is that much as I love the blackdown por
[ Late reply due to backlog. ]
On Sun, Sep 02, 2001 at 06:13:04PM -0500, Ben Burton wrote:
> Okay. I have a new proposal for java-common, namely the scripts
> /usr/bin/whichjava and /usr/bin/whichjavac.
>
> What these do is take the given Java interpreter/compiler and spit out
> properties su
On Fri, Jul 27, 2001 at 06:58:12AM -0500, Ben Burton wrote:
>
> > Oh. (Sheepishly looking in the archives for your script and
> > otherwise nosing around.) Well now, I'm not sure I see who is
> > helped by your script (in its current form).
>
> Well, the idea is that *every* java interpreter or
On Fri, Jul 27, 2001 at 06:58:12AM -0500, Ben Burton wrote:
>
> > Oh. (Sheepishly looking in the archives for your script and
> > otherwise nosing around.) Well now, I'm not sure I see who is
> > helped by your script (in its current form).
>
> Well, the idea is that *every* java interpreter o
On Wed, Jul 25, 2001 at 01:45:06AM -0500, Ben Burton wrote:
> Andrew Pimlott wrote:
>
> > Your script punishes the Debian developer who creates a clean
> > package for a new JVM, that registers an alternative for
> > /usr/bin/java and runs without any special help. Use
On Wed, Jul 25, 2001 at 01:45:06AM -0500, Ben Burton wrote:
> Andrew Pimlott wrote:
>
> > Your script punishes the Debian developer who creates a clean
> > package for a new JVM, that registers an alternative for
> > /usr/bin/java and runs without any special help. Use
[ Answering old mail. ]
On Tue, Jul 03, 2001 at 09:34:49PM -0500, Ben Burton wrote:
> Hi. Policy states that Java programs must run without specific environment
> variables, which can be some hassle when writing a program that works with
> several JVMs. Different JVMs use different bootstrap c
[ Answering old mail. ]
On Tue, Jul 03, 2001 at 09:34:49PM -0500, Ben Burton wrote:
> Hi. Policy states that Java programs must run without specific environment
> variables, which can be some hassle when writing a program that works with
> several JVMs. Different JVMs use different bootstrap
On Wed, May 30, 2001 at 02:31:17PM -0600, Eric Schwartz wrote:
> No, no, I mean what they seem to be saying is that you cannot modify the
> classes that define the API to either extend or contract the scope of the
> API. My interpretation of what they're saying is thus:
>
> "Anything that curre
On Wed, May 30, 2001 at 02:31:17PM -0600, Eric Schwartz wrote:
> No, no, I mean what they seem to be saying is that you cannot modify the
> classes that define the API to either extend or contract the scope of the
> API. My interpretation of what they're saying is thus:
>
> "Anything that curr
On Wed, May 30, 2001 at 01:03:48PM -0600, Eric Schwartz wrote:
> [EMAIL PROTECTED] (Andrew Pimlott) writes:
> > While this does allow modification of the software, it effectively
> > says that when you modify it, you must break the API. This seems
> > like an onerous requir
On Wed, May 30, 2001 at 09:08:03PM +0200, Egon Willighagen wrote:
> On Wednesday 30 May 2001 20:48, Andrew Pimlott wrote:
> > It is fine to split packages into the official API classes, and
> > supporting classes. However, it is not fine to say that there can
> > be only one
On Wed, May 30, 2001 at 01:54:52PM +0200, Egon Willighagen wrote:
> But it might indeed be "good" to place the interface classes in a seperate
> jar/package... this would enforce that the implementation *does* implement
> the actual interface, and not some look-a-like...
I may have misunderstood w
On Wed, May 30, 2001 at 03:25:09PM +0100, Toby Speight wrote:
> AIUI, the packages in question simply bundle W3C's interfaces[1]
> (unchanged - W3C's licence may require this)
I was curious about this, and I would like to ask if there is any
consensus on how this affects free software. For exampl
On Wed, May 30, 2001 at 01:54:52PM +0200, Egon Willighagen wrote:
> But it might indeed be "good" to place the interface classes in a seperate
> jar/package... this would enforce that the implementation *does* implement
> the actual interface, and not some look-a-like...
I'm don't think this is po
On Wed, May 30, 2001 at 01:03:48PM -0600, Eric Schwartz wrote:
> [EMAIL PROTECTED] (Andrew Pimlott) writes:
> > While this does allow modification of the software, it effectively
> > says that when you modify it, you must break the API. This seems
> > like an onerous requir
On Wed, May 30, 2001 at 09:08:03PM +0200, Egon Willighagen wrote:
> On Wednesday 30 May 2001 20:48, Andrew Pimlott wrote:
> > It is fine to split packages into the official API classes, and
> > supporting classes. However, it is not fine to say that there can
> > be o
On Wed, May 30, 2001 at 01:54:52PM +0200, Egon Willighagen wrote:
> But it might indeed be "good" to place the interface classes in a seperate
> jar/package... this would enforce that the implementation *does* implement
> the actual interface, and not some look-a-like...
I may have misunderstood
On Wed, May 30, 2001 at 03:25:09PM +0100, Toby Speight wrote:
> AIUI, the packages in question simply bundle W3C's interfaces[1]
> (unchanged - W3C's licence may require this)
I was curious about this, and I would like to ask if there is any
consensus on how this affects free software. For examp
On Wed, May 30, 2001 at 01:54:52PM +0200, Egon Willighagen wrote:
> But it might indeed be "good" to place the interface classes in a seperate
> jar/package... this would enforce that the implementation *does* implement
> the actual interface, and not some look-a-like...
I'm don't think this is p
Ok, it looks like my understanding of the details is lacking. I'll
try to keep this message on a higher level. Sorry for any
confusion.
On Tue, Apr 03, 2001 at 08:58:19AM -0700, Per Bothner wrote:
> [EMAIL PROTECTED] (Andrew Pimlott) writes:
> > On the other hand, if JNI is an
Ok, it looks like my understanding of the details is lacking. I'll
try to keep this message on a higher level. Sorry for any
confusion.
On Tue, Apr 03, 2001 at 08:58:19AM -0700, Per Bothner wrote:
> [EMAIL PROTECTED] (Andrew Pimlott) writes:
> > On the other hand, if JNI is an
On Tue, Apr 03, 2001 at 06:47:37AM -0400, egonw wrote:
> Indeed. But the principle holds that in Debian, with dependencies, that
> a certain executable exactly knows where to find a certain library.
Not true. Executables declare dependencies on soname's. It is the
job of the runtime linker to de
My background in these issues is modest, but I have a strong
interest in seeing them resolved, so let me try to add something.
On Mon, Apr 02, 2001 at 05:43:55PM -0700, Per Bothner wrote:
> So where should be put the .jar files? I suggest leaving this as
> /usr/share/java. However, we should add
On Tue, Apr 03, 2001 at 06:47:37AM -0400, egonw wrote:
> Indeed. But the principle holds that in Debian, with dependencies, that
> a certain executable exactly knows where to find a certain library.
Not true. Executables declare dependencies on soname's. It is the
job of the runtime linker to d
My background in these issues is modest, but I have a strong
interest in seeing them resolved, so let me try to add something.
On Mon, Apr 02, 2001 at 05:43:55PM -0700, Per Bothner wrote:
> So where should be put the .jar files? I suggest leaving this as
> /usr/share/java. However, we should ad
87 matches
Mail list logo
