Re: Let Jikes (finally) go into testing on its own...
On Wed, Jan 21, 2004 at 01:46:40PM +0100, Daniel Bonniot wrote:
> Stefan Gybas wrote:
>
> >Daniel Bonniot wrote:
> >
> >>One solution to this (which I found at
> >>http://www.mail-archive.com/debian-mentors@lists.debian.org/msg10605.html)
> >>would be to temporily make new (empty) versions of the jikes-* packages
> >>with priority extra, and that only depend on the new jikes-with-*
> >>packages.
> >
> >
> >This would require a new source package that builds these dummy package.
>
> You're right: they couldn't be in jikes because that would prevent the
> migration, and they couldn't be in the VM/runtime packages (except for
> gij) since they need a higher version number.
>
> Jikes-sun already is in a separate source package, with version 0.5. So
> we are speaking about classpath, kaffe and sablevm here.
>
> >If you have to introduce a new source package why don't you simply put
> >the real wrappers into it?
>
> Because those new packages are just temporary to force the upgrade, the
> goal being to get rid of them. The real packages cannot be in the same
> souce package as the dummy ones, since that would force them to have the
> same version.
>
> So it seems there are 3 options:
> * include the wrappers in the main binary package of the VM, using an
> epoch to force upgrade and adding Depends on jikes
> * include the wrappers in the main source package of the VM, using an
> epoch to force upgrade
> * include the wrappers in the main source package of the VM, and add
> a new source package with a dummy wrapper that depends on the new one.
> Remove this dummy package after sarge is released
>
> Is it important to try to agree on a scheme, or should we just let each
> JVM packager decide which one to apply?
>
> (For gij, the epoch is not necessary, so the second solution is probably
> the best)
Well, the second solution is the ONLY solution that makes any sense.
1. People installing a VM do not need to install jikes so first one is out.
2. The entire point of putting wrappers in the source package of another
package (like a compiler, or JVM), is to not bloat the /pool with
stupid little 20 byte sources.
Increasing the epoc should not be a problem since epoc is generally not used
upstream. The version does not look any different in dselect,
__ Opt devel jikes <none> 1.15-2 Fast Java compiler...
.
.
Version: 1:1.15-2
It does look different in other places, but for most part, I think people
are intelligent enough to figure out the version by themselves :)
Futhermore, I think that most users using Debian do not necessarly track the
upstraem version numbers. I do not really care what version 'tar' is, as
long as when it comes to upgrade, all that happens is that new 'tar' gets
installed. I do NOT want to see 'tar-new' + 'tar2' get installed, 'tar'
uninstalled and 'tar-new' to be a dummy package!
The epoch change causes LEAST amount of pain for the users while not
bloating the archive with new 20byte sources.
- Adam
Reply to: