[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [PROPOSAL] New Virtual Packages and way to handle Classpath



On Thu, 2003-08-28 at 18:39, Jan Schulz wrote:
> On package system level, it isn't a problem. It becomes a problem,
> when you have alternatives. I have a VM, which provides java.net and
> java2-runtime-1.4 and another VM, which provides java.nio and
> java2-runtime-1.4. Now we have Program, which Depends on nio *and*
> net and jre1.4.  apt will install both VMs and the program will call
> /usr/bin/java-1.4 and will think that everything should work. And it
> will not, as on of the java packages is not in the classpath.
> 
> Therefore we need alternatives for each combination of virtual packages:
> VM -> Provides: net, nio
> -> provides alternatives for java-nio, java-net and java-nio-net
> 
> Even if you could setup the bootclasspath in your packages, this
> wouldn't work, as this would mean, that we have to seperate the
> rt.jar of the bigger VMs. This would break for example every IDE
> out there.

Why is there a one-to-one relationship with provides/depends and
alternatives? You can certainly have:

foojvm:
provides: java.net, java.io, java.awt
/usr/share/java/rt.jar -> 
	/etc/alternatives/rt.jar -> 
	/usr/share/foojvm/rt.jar

barjvm:
provides: java.net, java.io, java.nio
/usr/share/java/rt.jar -> 
	/etc/alternatives/rt.jar -> 
	/usr/share/barjvm/rt.jar

But having a single definative java and a single definative base class
jar seems to imply conflicts between VMs. It doesn't have to be that
way. Its not even clear to me that the /etc/alternatives approach even
works for Java. Base rt.jar alternatives don't really seem that
desirable to me.

How often does Debian have packages that depend on a group of other
packages that provide partial and competing support for the same
standards? I know GTK has similar problems but at least it only has
version problems rather than DebianGTK -vs- XimianGTK.

> The other thing is, that IMO noone wants to run tomcat under full load
> on a JVM, which doesn't do any JIT compilation. This is real world, 
> too...

A. Kaffe has a JIT compiler.
B. It doesn't matter what proprietary software provides. This is Debian.

-- 
_____________________________________________________________________
Ean Schuessler                                      ean@brainfood.com
Brainfood, Inc.                              http://www.brainfood.com




Reply to: