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 java"). 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@tks6.net Bern, Switzerland http://jw.tks6.net