Re: [PROPOSAL] New Virtual Packages and way to handle Classpath
Hallo Ean,
* Ean Schuessler wrote:
>On Thu, 2003-08-28 at 18:39, Jan Schulz wrote:
>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
Becaus you can install both javas next to each other. From the package
system, all Depends: are satisfied, but when you call java (rt.jar is
just a different level) not all dependencies are on the bootclasspath.
Your aproach is only possible, when you Conflicts: with each other and
therfore only have only one JVM installed.
>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.
It should at least work for the unfree VMs. This would let us at least
get away from this PITA, which it currently is.
>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.
motif is IMO similar. But there at least you have all as packages and
not some installer script.And you don't have so much changing API.
>> 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.
I didn't know that. I know that gcj doe not (for exapmle all eclipse
plugins, which couldn't be compiled to native (see the RedHat eclipse
ML) are running in interpreter mode. Or all added plugins.
>B. It doesn't matter what proprietary software provides. This is Debian.
Yes. And we should at least make this situation for our users as easy
as possible. The situation now is IMO not.
I haven't done it, but this is IMO the way how someone would install
Tomcat on a debian server:
apt-get install apache
apt-get install tomcat4 # does not work, as there is no j2sdk in debian
# two ways: get BD packages, which are outdated by almost a year and
# beta. Or use equies and a -bin downlaod. Or, worst: install BD and
# then get a -bin download and hack the /etc/default/tomcat4
apt-get install tomcat4
Similar things for the browser plugins.
Jan
--
Jan Schulz jasc@gmx.net
"Wer nicht fragt, bleibt dumm."
Reply to: