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

Re: java library installation issues

Op dinsdag 03 april 2001 19:00, schreef Per Bothner:
> > Or maybe, to have two conflicting packages program and program-gcj?
> I've concentrated on where things get installed, not so much on how
> things get split into package, but here are soem notes on the latter.
> For libraries it might be reasonable to have two packages:
> (1) 'library' installs a .jar files (and documentation).
> (2) 'library-gcj' depends on 'library' and 'gcj-runtime', and
> installs a .so file.
> The main downside of this approach is lots of little packages,
> so it is mainly an issue of how distributions deal with (hide) this.
> For example, it is possible that 'library-gcj' could be hidden from
> from the default package management view, but automatically installed
> if both 'library' and 'gcj-runtime' are installed.
> Absent something like this, it may be simpler to just have a single
> package.  If installing 'library' also installs program.so.

I guess you're right... a libXXX-java should preferably also install
a compiled version for it. Though, this should not be policy (ofcourse).

> For programs it is harder, because a native-compiled executable
> won't run without the gcj runtime libraries.  One option is the
> shell script route:  the script looks for a native-compiled
> executable and if it doesn't find it load a jvm.  I don't think
> resolving this needs to be an issue for a generic GNU/Linux
> FHS, but it is an issue for individual distributions.  I think
> Red Hat should just require gcj-runtime for any Java package
> that can be compiled to native, because Red Hat should support gcj,
> and Red Hat has not traditionally dealt with thousands of packages.
> For Debian the choice might be different.

I think this is up to the packager. If he compiled his code natively, he has
depend both for compilition and for executing on gcj.

I know this has in principle nothing to do with where the native code should
be installed... but if we want to adapt the Debian Java policy, these things
have to be resolved (at least for Debian).


Reply to: