Re: Let Jikes (finally) go into testing on its own...
I asked at #debian-devel and was adviced to contact debian-release.
So this is mainly for debian-release to take a look at.
W liście z sob, 17-01-2004, godz. 06:38, Mark Howard pisze:
> On Sat, Jan 17, 2004 at 12:44:34AM -0500, Grzegorz B. Prokopski wrote:
> > The problem is known, I pointed it out here at least once. Jikes
> > provides all these wrappers jikes-* for different JVMs. This makes the
> > source package dependant on ALL these JVMs. The result is that if ANY
> > [*] them has problems going into testing - jikes has this problem too.
>
> Could you please explain this further? To get into testing, why do these
> jvm packages hold jikes up? Once all the packages have some version in
> testing (which seems to be happening very soon), jikes will always get
> into testing, even if these packages have RC bugs and are not themselves
> getting newer versions into testing.
>
> Jikes does not need versioned dependencies on these packages, so I don't
> see what the problem is.
You're right, all these JVMs are in testing.
http://qa.debian.org/developer.php?excuse=jikes
Currently we have these excuses:
* jikes-classpath/arm unsatisfiable Depends: classpath
* jikes-gij/hppa unsatisfiable Depends: libgcj4 | libgcj3 | libgcj2
* jikes-sablevm/hppa unsatisfiable Depends: sablevm (>= 1.0.5-1)
* jikes-gij/mips unsatisfiable Depends: libgcj4 | libgcj3 | libgcj2
* jikes-kaffe/mips unsatisfiable Depends: kaffe
* jikes-sablevm/mips unsatisfiable Depends: sablevm (>= 1.0.5-1)
* jikes-gij/mipsel unsatisfiable Depends: libgcj4 | libgcj3 | libgcj2
* jikes-kaffe/mipsel unsatisfiable Depends: kaffe
* jikes-sablevm/mipsel unsatisfiable Depends: sablevm (>= 1.0.5-1)
all jikes-* are Architecture: all.
And ex. there has never been classpath for arm (see
http://packages.debian.org/classpath) nor there has never been sablevm
packages for mips and mipsel.
So from common-sense POV - I fail to see why newer version of jikes
should be held in unstable.
The first suggestion I got was:
<gadek> could anyone please take a look at
http://qa.debian.org/developer.php?excuse=jikes ? I don't understand
why ex. if there has never been classpath on arm, jikes-classpath is
being held by it.
<yp17> gadek: I don't think the testing script is clever enough. It only
look whether there have been a jikes-classpath packages.
<Ganneff> or ask the -release list to add a hint for it?
<Ganneff> hint for the testing scripts.
<Ganneff> to add a hint to do something the scripts wont do itself.
Other suggested action was:
<yp17> gadek: you can use Arch: !arm for the time being.
but this is very inconvinient because it'd require _jikes_ maintainer
to track on what architecturea are _all_ these JVMs available or not
and how it changes.
Yet another suggestion, with which this debian-java thread was started,
was to move all these wrappers pacakges into respective JVM, which would
automatically mean that they're controlled by JVMs' maintainers and
they're built only on the arches where each JVM is built.
Would testing sctipts handle it gracefully then?
We want newer jikes to be promotable to testing.
debian-release - what do you suggest?
Grzegorz B. Prokopski
--
Grzegorz B. Prokopski <gadek@debian.org>
Debian GNU/Linux http://www.debian.org
SableVM - LGPLed JVM http://www.sablevm.org
Reply to: