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/[EMAIL PROTECTED]/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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
