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

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



On Tue, 2003-09-02 at 16:10, Jan Schulz wrote:
> And how is that differently from my aproach? j2sdk1.4 is just a word
> for 'Sun compatible J2sdk of version 1.4'. mpkg-j2sdk will make a
> package with that name from the sun -bin download (BD gets
> j2sdk1.4-bd). So you are basicly hiding working VMs form the packageing
> system. How nice, if a user has to download 30MB, just to satisfy the
> dependencies and then setting JAVA_HOME to the newer -bin downlaod.

The difference is that the Kaffe package would not try to provide
"j2sdk1.4". Kaffe just provides "kaffe". Packages that know they will
work with Kaffe can explicitly depend on it.

The problem is that "java2-runtime-<spec-version>" doesn't really
provide anything more than "j2re1.4". It is just a wordier way to refer
to Sun and IBM's VM, neither of which can actually be distributed by
Debian.

Something I have just now thought of that might make more sense. What if
we use Classpath as the standard instead of the Sun VM releases?

Therefore,
Kaffe: provides: Classpath-0.5
ORP: provides: Classpath-0.5
J2SDK1.4: provides: Classpath-0.5
Tomcat4: depends: Classpath-0.5

The only trouble is that Classpath-0.5 is Classpath's actual version and
not some sort of intentional demarcation of features. Maybe what we need
is some sort of Free Java feature spec that is loosely based on
Classpath. I think Classpath is pretty representative (if not
fundamental) for the various Free VMs that are out there.

debian-javabase-1.1 : Things that are mostly our idea of 1.1
debian-javabase-1.2 : Things that are mostly our idea of 1.2
debian-javabase-1.4 : Some fictional thing that doesn't exist.

> And the thing is, it will work. JAVA_HOME is not advertised anywhere,
> but almost every startscript uses it. man ant, man eclipse, man
> tomcat4 (oups: "No manual entry for tomcat4", which tomcat4:
> /usr/bin/tomcat4). All use it, but no word in the man page (eclipse is
> my package, so consider this as 'will be fixe din the next
> upload'...).

Kaffe is actually mostly compatible with the JAVA_HOME "standard" now
that I use symlinks for Debian compatibility. It might be worth making
the JAVA_HOME structure part of Debian policy. GCJ and friends could
create some simulation of it by symlinking stuff into a fake JAVA_HOME
structure.

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




Reply to: