[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Use of update-alternatives or JAVA_HOME (was: Experience in converting to GCJ)



On Monday 11 August 2003 21:18, Matt Zimmerman wrote:
> On Mon, Aug 11, 2003 at 09:58:03PM +0200, Jan Schulz wrote:
> > * Matt Zimmerman wrote:
> > >JAVA_HOME seems silly in Debian, where we have alternatives to manage
> > > these things.  I wish it would go away.
> >
> > I do not!
> >
> > The current update-alternatives system isn't working, when you don't
> > have a way to prevent 'not fit to the work' /usr/bin/java to use it.
> >
> > Curently my /usr/bin/java is assigned to the blackdown packages, but
> > almost eveywhere else I use a more up2date jdk (all of them
> > unfortunatelly not even managing u-a).
>
> I don't understand.  What does JAVA_HOME provide that you cannot achieve
> with alternatives, besides compatibility with programs which expect
> JAVA_HOME (which is a truism)?

The problem is that it is used all over the place in the Makefiles for 
kdebindings.  I need something that will coexist in both the Debian world
and the RPM world.

>
> > What I would like to see:
> >
> > * add a script/way to recognise/install/make known any installed
> >   /bin/java, together with some rules/infos, what cpabilities this
> >   java has.
> > * add a script to java-common, which returns a appropriated java, based
> > on . version and api needed
> >   . user settings in JAVA_HOME
>
> This is what update-alternatives does.
>
> --
>  - mdz



Reply to: