[JPackage-discuss] Proposal for IBM JVM packaging changes

Thomas Fitzsimmons fitzsim at redhat.com
Thu Mar 25 15:24:03 CET 2004


On Thu, 2004-03-25 at 05:01, Henri Gomez wrote:
> Thomas Fitzsimmons wrote:
> 
> > On Wed, 2004-03-24 at 18:37, Nicolas Mailhot wrote:
> > 
> >>Le mer, 24/03/2004 à 14:29 -0500, Thomas Fitzsimmons a écrit :
> >>
> >>
> >>>Hello,
> >>>
> >>>I've made some changes to the IBM JPackage spec files.  I'll list each
> >>>change and the rationale for it.
> >>
> >>Some comments (I don't have a lot of time to do jpp packaging these days
> >>so do not take this as mandatory changes in any way)
> >>
> >>
> >>>Plug-in Handling
> >>>================
> >>>
> >>>- remove triggers
> >>>
> >>>  Triggers should only be used in emergencies, because they are
> >>>inherently error-prone.  Triggers make assumptions about other
> >>>to-be-installed packages' behaviour (call them the "trigger" packages). 
> >>>If any of those assumptions causes a failure in the trigger script
> >>>fragment, then the trigger packages will be left installable.
> >>
> >>Some triggers were needed back in the day. They can be taken out if we
> >>stop supporting very old distros. Others may need to be kept.
> >>
> >>
> >>>- manage Java plug-in and ControlPanel with update-alternatives
> >>>
> >>>  To replace the trigger functionality, I've created a libjavaplugin.so
> >>>alternative.  This is the best way of handling multiple Java plug-in
> >>>installations, since Mozilla has no interface for selecting from a set
> >>>of plug-ins that all handle the same MIME type.
> >>
> >>Argh ! triggers can be tricky but in my experience alternative can get
> >>(much) worse. The plugin is something that doesn't need parallel install
> >>- just make plugin subpackages conflict with each other and you'll be
> >>done.
> >>
> > 
> > 
> > I did try this approach, but I don't think it's ideal.  If users have
> > the ability to smoothly switch their Java runtime environment then they
> > should also be able to switch Java plug-ins (and accompanying
> > configuration programs like ControlPanel) just as smoothly.  And what
> > about developers who want to test applets with multiple different
> > plug-ins?  Having to switch plug-in rpms is very clunky.
> > 
> > 
> >>The only reason we have a trigger in plugin is not for // install but
> >>because early version of moz didn't look for plugins
> >>in /usr/lib/mozilla. If it's been fixed just remove the trigger and
> >>inconditionnaly install in /usr/lib/mozilla. The trigger is mostly used
> >>right now to move the link from /usr/lib/mozilla/1.n/plugins
> >>to /usr/lib/mozilla/1.n+1/plugins on mozilla upgrades.
> >>
> > 
> > 
> > Yes, this is fixed in current versions of Mozilla, so the
> > libjavaplugin.so alternatives link is installed in
> > /usr/lib/mozilla/plugins.
> > 
> > 
> >>>Multi-arch Support
> >>>==================
> >>>
> >>>  Binary tarballs are available on IBM's site for i386, ppc, s390, and
> >>>s390x architectures.  I've added %ifarch clauses for each of these
> >>>architectures.  People wanting to build only on i386 can limit the
> >>>ExclusiveArch list to i386.
> >>
> >>I think some of the ibm jvms already have multiarch support
> >>
> > 
> > 
> > The 8jpp .nosrc package didn't support multiple architectures.
> 
> The 9jpp, has been used on Suse (PPC 32 and 64) and Fedora :-)
> 

Where's 9jpp?  http://www.jpackage.org/rpm.php?id=2299 has only 8jpp.

Any thoughts on the rest of the changes?

Tom





More information about the JPackage-discuss mailing list