[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 11:11:06AM -0700, Dalibor Topic wrote:

> > I used to be very busy/without net during last months but I am back.
> > And attacking ;-)
> > 
> > The problem is that currently jikes (in the sense of source package,
> > which is important from testing migration scripts POV) depends of
> > a whole pile of packages. Just take a look:
> > http://qa.debian.org/developer.php?excuse=jikes
> > 
> > The problem is that jikes privides wrappers which depend on every
> > possible JVM in Debian. So for ex. if *ANY* of them won't make it
> > into testing - we won't have jikes in testing and thus in stable! [0]
> > 
> > Probably the proper fix for that would be that creation of wrappers
> > should be only up to JVM/classpath maintainers and be done by them,
> > probably in their JVM/classpath packages.
> 
> Wouldn't it be better to provide the wrappers as separate jikes-on-xyz
> packages, that would depend on both jikes and the VM/classpath package?

Er...this is exactly what jikes does.

mizar:[~] apt-cache show jikes-{kaffe,gij,sablevm,classpath} |grep Depends
Depends: jikes, kaffe, java-common
Depends: jikes, libgcj4 | libgcj3 | libgcj2, java-common
Depends: jikes, sablevm (>=1.0.5-1), java-common
Depends: jikes, classpath, java-common

> jikes could depend on any one of the wrapper packages being installed, if
> that's possible with debian's dependency system.

Jikes doesn't need to depend on any of them because it can be used on its
own.

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.

-- 
 - mdz



Reply to: