[clc-devel] A few thoughts on Java and Games

Johannes Winkelmann jw at tks6.net
Fri Oct 8 05:53:32 UTC 2004

Hi there,

On Thu, Oct 07, 2004 at 17:14:18 -0700, Jay Dolan wrote:
> Hi guys,
> I was wondering if anyone is objected to removing the (outdated)
> quakeforge port from unmaintained.  It's sortof an oddball, anyway.
> But the main reason I ask is because I maintain a full set of Quake
> related ports in my httpup repository.  They're all current and adhere
> to a uniform structure.  Quakers could get most of what they need from
> there, leaving clc's collections for more ..serious things ;)
Hehe, sounds good, please go ahead. I think there should be room for
games in a contributed ports repository though, so at a later point in
time, I wouldn't mind seeing all of them in CLC again.
I actually have a note in my cruxcon preparation mentioning games :-)

> Regarding Java.. listing Java as a dependency is a pain in the butt,
> as I'm sure we can all agree.  Currently two redundant ports, j2re and
> j2sdk, live in contrib.  J2re is most often used as the core
> dependency for Java applications, and rightly so.  But this solution
> nudges people who already have j2sdk installed towards downloading a
> big tarball to build an almost identical pacakge for j2re.
> Can the two be merged to create a "java" metaport that
> installs the j2sdk and some symlinks in /usr/bin?
I'd suggest we delay this decision and discuss this at CRUXCon, since it
covers some quite general issues like "virtual dependencies" and ports
which exists in different implementations... e.g. one might want to have
different SDK's installed at the same time (1.1.8, 1.3, 1.4.x, 5.0,
IBM's SDK, Blackdown's...) and switch between them; another example is
OpenGL implementation, where one might have nvidia and Mesa3D installed,
and would like to occasionally test whether his/her software works with
software rendering as well. 
Whatever solution we go for (symlinks etc.), we might consider creating
a mechanism which can also be used after installation, like
  $ java-select 1.1.8
  $ opengl-select mesa3d

These tools could then be used in post-installs scripts as well, and be
mentioned in the README ("Please either run the post-install script or
execute java-select x.y.z to select this SDK as your current default
We should just check whether it is overkill for the two cases I've
pointed out here, or whether there might be more to come.

The dependency handling by use of metaports works fine, but I guess
dependencies will be a hot topic at CRUXCon anyway, so if no one
objects, let's just make mental notes here :-)

Kind regards, Johannes
Johannes Winkelmann              mailto:jw at tks6.net
Bern, Switzerland                http://jw.tks6.net

More information about the crux-devel mailing list