JAVA_HOME vs. FHS [was: Re: SableVM SDK - suggested patch]

"Grzegorz B. Prokopski" <[email protected]> Sat, 21 May 2005 16:10:40 -0400
Newsgroups gmane.comp.java.vm.sablevm.devel
Organization SableVM - LGPL'ed Free Java VM http://sablevm.org
Message-ID <[email protected]>
On Sat, 2005-21-05 at 00:00 -0400, David Bélanger wrote:
> What about this patch for SableVM SDK?
> 
> It specifies bindir, libdir, ... via module specific configure
> options.

Ok, let's first see what would be the best approach here.  The problem
is that we have *two* standards to follow.  One is FHS, which tells
us where to install binaries, native libraries, manual pages, and other
architecture-independant data.  The other is the de facto standard which
is JAVA_HOME structure.  Ideally we should try to conform to both.

The current solution in SableVM SDK is imperfect.  For example I simply
drop the binaries to something like /usr/local/lib/sablevm/bin, and jars
to /usr/local/lib/sablevm/lib.  This is easier to do and follows the
latter standard, but not the first one.

What I see as a solution here, is to install all our binaries into
standard FHS locations, but give them -sablevm suffix (like we do
already for some of them) to avoid conflicts with system-wide
installations if they are done after, or if we're asked to install
our versions.  Then in JAVA_HOME - only put (relative!) symlinks to
these binaries.  The same for .jars, which should go into sth.
like /usr/local/share/sablevm, as architecture-independant data,
and for manuals, which would go into /usr/local/man/.

I'd be glad to hear any better ideas, but unless you have some, it would
be best to work on patches would realize the above solution.  So yes,
the $prefix/lib/sablevm would pretty much become a symlink pool, which
I don't think is any problem (just make them relative, not absolute).

Actually, having binaries and manual pages for them installed in FHS
locations means easier access to manuals, which is not the case when
they're hidden in /usr/local/lib/sablevm/man dirs.

The last, but not the least.  Altough I prefer to make only minimal
changes to upstream sources, I would not be afraid of cosmetic changes
like changing names of the binaries [*].

If you have any questions about some general ideas or solutions behind
SableVM SDK build system, etc. I'll be glad to answer.

HTH,

				Grzegorz B. Prokopski

[*] When changing the names of binaries bear in mind, that in SableVM
SDK there are scripts in 'bin' source directory (they're used at stage
3-'EXTRA' of compilation/configuration), which refer to not yet
installed binaries, libraries, jars etc.  So you need to update them if
the names of not yet installed components change.
-- 
Grzegorz B. Prokopski           <[email protected]>
SableVM - Free, LGPL'ed Java VM  http://sablevm.org
Why SableVM ?!?                  http://sablevm.org/wiki/Features
Debian GNU/Linux - the Free OS   http://www.debian.org