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

Re: newer jikes may never get to testing (and thus stable)



On Sat, Sep 06, 2003 at 03:03:29PM -0400, Grzegorz B. Prokopski wrote:
> On Sat, 2003-09-06 at 14:32, Matt Zimmerman wrote:
> > What you are missing is that Debian binary packages must stay in sync with
> > their source package, which means that all of the packages that jikes builds
> > are handled as a group for release purposes.
> > 
> > If this is causing a problem, the obvious solution is to move the jikes-*
> > packages into separate source packages to allow them to be handled
> > separately from jikes itself.
> 
> Yup - it think it should be up to JVM maintainers to create those
> wrappers either:
> 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

Attachment: signature.asc
Description: Digital signature


Reply to: