Re: newer jikes may never get to testing (and thus stable)
I don't see that putting the wrappers in the JVM package is a good
solution. It would be like libc6 having wrappers for a bunch of programs
that expect libc to be in some unusual location. Eventually Kaffe will
have dozens or hundreds of wrappers in its package and would, I guess,
depend on all of the things that it provides those scripts for.
Actually, I can't even make sense of how it would work. I'm sure I'm
just dense. Someone please explain the plan to me again.
I believe the proper solution is to more fully define the JAVA_HOME ad
hoc standard in terms of the Debian environment and then do whatever is
necessary to each VM to provide that standard environment. If Jikes just
expects the JVM to have bin/java and jre/lib/rt.jar then Kaffe should
already be there. This standard can be called debian-java or
debian-java-home or whatever and packages like Kaffe can provide it.
Since the J2SDK and J2RE packages currently provide this interface and
Kaffe mostly provides it I would think that this is the path of least
resistance.
On Fri, 2003-09-19 at 02:14, Adam Majer wrote:
> > 1. In their JVM binary package
> > 2. As separate binary package built from JVM source package
> > 3. As separate binary package built from *own* source package.
> >
> > My favourite would be 1. or 2. but if one would belive that one day
> > jikes may not get into testing - then 3. would be the way to go.
>
> Jikes only depends on the the basic libraries:
> libc6 (>= 2.3.2-1), libgcc1 (>= 1:3.3.1-1), libstdc++5 (>= 1:3.3.1-1)
>
> So it will pretty much always go into testing if on its own.
>
> Personally, I really do not like #3 since it just makes more crap in
> the archive.... #1 would require every single user of
> the JVM to install jikes along with it.. That might not be the best thing..
> #2 is the best proposal...
>
> #2 would be a little messy though - I would have to:
> 1. upload new jikes without any wrappers included
> 2. get all of the wrappers removed from Sid
> 3. All JVM (classpath, kaffe, sablevm, gij) would need to start to
> provide an up-to-date jikes-* package... This should not be too difficult.
>
> Of course, there is the #4 way of getting jikes into testing - ie. fix
> Kaffe and Classpath. :) Right now, I'm worried much more about Kaffe than
> I am about Classpath.
> http://qa.debian.org/developer.php?excuse=classpath
>
> # 24 days old (needed 10 days)
> # classpath/hppa unsatisfiable Depends: libgcj-common
> # classpath/mips unsatisfiable Depends: libgcj-common
> # classpath/mipsel unsatisfiable Depends: libgcj-common
> # Valid candidate
>
> It seems that libgcj-common is not provided
> for those archs hence classpath should not
> be provided for those archs. Comments?
>
>
> The FTBFS for Kaffe are all C related. I'll try to fix these
> tomorrow... The one for S390 seems to be package related -
> the rt.jar gets deleted before it gets installed?? hmm??
>
> - Adam
--
_____________________________________________________________________
Ean Schuessler ean@brainfood.com
Brainfood, Inc. http://www.brainfood.com
Reply to: